Hirdetés

Keresés

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

  • Sk8erPeter
    nagyúr

    Szvsz a TDD nem advanced dolog, hanem alapvető, ha fejleszteni akarsz. Ha nem ismered, nagyjából arról szól, hogy először a tesztet írod, utána meg az implementációt, mindezt kis kód részletekben. Így a végére a kód nagyjához lesz automatizált teszted. Menet közben is hasznos, mert a hibák azonnal kiderülnek, és nem kell utánanyomoznod órákat debug-al, hogy hol hasal el a kód. Én már inkább a BDD fele hajlok, annál először szövegesen írod le, hogy mit akarsz, aztán azt fordítod át tesztekre. Így a teszteket bármikor kicserélheted, úgy, hogy a szöveg változatlan marad. Ez sokkal rugalmasabb, mint a TDD, pl ugyanazok alapján a leírások alapján egy csomót azonos képességű eltérő klienst tudsz fejleszteni, esetleg eltérő API-kat kipróbálni, és így tovább.

    "Szvsz a TDD nem advanced dolog, hanem alapvető, ha fejleszteni akarsz"
    Bocs, de most már muszáj beszólnom, annyira folyamatosan erőlködsz ezzel a TDD-BDD-HDD-SSD-DDD-XXX-ASDASD-QWEQWE-BLABLA-HABLATY-vonallal (:]), hogy kezd már picit irritáló lenni. Azért komolyan kíváncsi lennék, hogy létezik olyan munkahely, ahol a fejlesztők tényleg MINDEN kódot TDD/BDD/akármi-vezérelt elven írnak? Van erre idő? (Persze elméletben ez is létezhet, ahol irreálisan nyugis a tempó.) Csak mert általában a megrendelők várnak a termékükre, a főnökök az eredményre (joggal), majd jön a következő feladat, és így tovább. Vagy ezek csak jól hangzó elvek, amiket a hobbiprojektjeidnél alkalmazol? Mert az egyébként úgy tök jó, és szép dolog, de amúgy akkor még csomó vezérelvhez tartozó mozaikszót vagy buzzwordöt be lehetne dobálni, ami a gyakorlatban azért inkább fenntartásokkal kezelendő, mert vagy működik, vagy nem, jó, ha sikerül annak mentén csinálni, de sokszor inkább az erre való törekvés jön csak össze (és már az is valami).

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