Hirdetés

Keresés

Új hozzászólás Aktív témák

  • axioma
    veterán

    Túl cinikus vagyok a TDD-hez :)
    Az utóbbi években csak olyan agilis projektekben dolgoztam, ahol az agilitás leginkább arra vonatkozott, hogy menetközben találja ki a megrendelő, hogy mit is akar (vagy nem). A projektek óriási keretrendszereket használnak, amiben az egyes funkciók deklaratív elemeken keresztül automatikusan készülnek el. Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek.
    Ha ilyen projektekre valaki rávág egy coverage kritériumot, mert az jól mutat, a teljes csapat egy emberként áll fel, és megy át a konkurenciához.
    De hello ${username} példakódban piszkosul jól mutat...

    Vagy csak olyanok kozott dolgozom akik a problemat oldjak meg a szoftver letrehozasaval es az implementacio helyesseget tesztelik megfelelo szintu tesztekkel utat helyesebbnek tartjak.
    Tesztet irni TDD-hez DE ugy, hogy az tenyleg minden lehetseges implementacio eseten minden hibat elkap, akkora befektetes, hogy annyi ido alatt az _egyik_ implementaciot tesztelessel egyutt egy-harom masik problemara is megcsinalja [JOL]. Teljes tesztet elore megirni ugy, hogy egy lehetseges implementacio mar a fejeben van, az meg a menet kozben kiderulo donteseknel csinal lyukat [aztan vagy betomik vagy nem... talan ahol merge feltetelbe fut].
    Egy esetben jo lehet: az "agy" irja a teszteket, a code monkey-k/juniorok/etc. meg az implementaciot. De akkor sem biztos hogy kicsit is hosszabb tavra nezve.
    [Termeszetesen az elozoleg irt kiveteleket fenntartva, altalanosabb meretu/beagyazottsagu/bonyolultsagu fejlesztesi feladatokra.] Es persze SZVSZ.

  • btraven
    őstag

    Túl cinikus vagyok a TDD-hez :)
    Az utóbbi években csak olyan agilis projektekben dolgoztam, ahol az agilitás leginkább arra vonatkozott, hogy menetközben találja ki a megrendelő, hogy mit is akar (vagy nem). A projektek óriási keretrendszereket használnak, amiben az egyes funkciók deklaratív elemeken keresztül automatikusan készülnek el. Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek.
    Ha ilyen projektekre valaki rávág egy coverage kritériumot, mert az jól mutat, a teljes csapat egy emberként áll fel, és megy át a konkurenciához.
    De hello ${username} példakódban piszkosul jól mutat...

    Ha már Hello World.
    Azt hogy kell TDD-ben csinálni?
    Hogy állapítja meg a teszt hogy kiírta-e a képernyőre hogy Helló világ?
    És a jó pozícióba. Nem csak Helló vi és a lág meg kilóg oldalt.

  • BE4GLE
    senior tag

    Túl cinikus vagyok a TDD-hez :)
    Az utóbbi években csak olyan agilis projektekben dolgoztam, ahol az agilitás leginkább arra vonatkozott, hogy menetközben találja ki a megrendelő, hogy mit is akar (vagy nem). A projektek óriási keretrendszereket használnak, amiben az egyes funkciók deklaratív elemeken keresztül automatikusan készülnek el. Ritka volt az, amikor nem változott hétről hétre a követelmény, és nagyon kevés része volt a kódnak az, amiben unit tesztre érdemes dolgok történtek.
    Ha ilyen projektekre valaki rávág egy coverage kritériumot, mert az jól mutat, a teljes csapat egy emberként áll fel, és megy át a konkurenciához.
    De hello ${username} példakódban piszkosul jól mutat...

    Amit leírtál az távolról sem agilis fejlesztés. A rossz menedzsment mindig rányomja a bélyegét a projektminőségre. Ez nem a TDD hibája.

Új hozzászólás Aktív témák