Tervezésvezérelt tesztelés: Okosabban teszteljen, ne keményebben

Olvasói vélemények

A 'Design Driven Testing: Egyes olvasók dicsérik a tesztelési módszertannal kapcsolatos meglátásait, mások pedig kritizálják, hogy elfogultan támadja a tesztvezérelt fejlesztést (TDD). Míg egyesek szerint a könyv hasznos forrás, amely egyértelműséget és gyakorlati példákat nyújt, mások úgy érzik, hogy nincs benne tartalom, a szerzők más munkáit népszerűsíti, és pontatlanságokat tartalmaz a TDD-vel kapcsolatban.

Az olvasók nagyra értékelték a könyv friss szemléletét a tesztelési módszertanokkal kapcsolatban, különösen azt, hogy a könyv a hagyományos tesztvezérelt fejlesztéssel (TDD) szemben a tervezésvezérelt tesztelésre (DDT) helyezi a hangsúlyt. Az írói stílusról megjegyzik, hogy világos és tömör, a gyakorlati példák pedig segítik a fogalmak megértését. Egyesek hasznos forrásnak találták a szoftverfejlesztés tesztelési technikáinak javításához.

A kritikusok szerint a könyv megfelelő megértés nélkül elveti a TDD-t, és tele van pontatlanságokkal az agilis módszertanokról. Néhányan úgy találták, hogy a könyv inkább a szerzők saját termékeinek, különösen az ICONIX-nak a promóciós anyaga, mintsem a DDT tisztességes feltárása. Emellett a könyv feltételezi bizonyos eszközök és korábbi munkák ismeretét, ami korlátozhatja a könyv hozzáférhetőségét a szélesebb közönség számára. Több kritikus ismétlődőnek és száraznak minősítette a tartalmat.

(11 olvasói vélemény alapján)

Eredeti címe:

Design Driven Testing: Test Smarter, Not Harder

Könyv tartalma:

Ebben a fejezetben bemutattuk, hogyan lehet a szoftvertervezésből kiindulva egységteszteket vezetni, szisztematikusan azonosítva a tesztforgatókönyveket, ami biztosítja, hogy a kódot minden megfelelő helyen lefedjük.

Bemutattuk továbbá a "stunt services" és a mock objektumok használatát a tesztelt kód izolálására; végül pedig megvitattuk a unit tesztek mélyebbre vezetését az algoritmikus kódban, amely számára előnyös lehet a finomabb szemcséjű tesztelés. Van-e mód arra, hogy a fejezetben bemutatott átfogó egységtesztelés 95%-át lényegesen kevesebb teszteléssel érjük el? A következő fejezetben megmutatjuk, hogyan lehet pontosan ezt elérni a vezérlőtesztekkel.

Mint látni fogja, a unit teszteknek megvan a maguk helye, de a vezérlőtesztek gyakran okosabb, strukturáltabb megközelítést jelentenek az alkalmazás tesztelésében. 136 C H A P T E R 6???? Koncepcionális tervezés és vezérlőtesztelés Amint azt az 5. fejezetben láthatta, az egységtesztelésnek nem kell minden egyes kódsort, sőt még csak nem is minden egyes metódust kimerítően tesztekkel lefednie.

A csökkenő hozam - és a növekvő nehézség - törvénye érvényesül, ahogy a kódlefedettség százalékos arányát egyre magasabbra toljuk. Ha egy lépést hátralépünk, és szélesebb körben tekintünk a tervezésre, akkor kiválaszthatjuk a kód azon kulcsfontosságú területeit, amelyek input/output csomópontként működnek, és a teszteket ezekre a területekre összpontosíthatjuk.