Skip to content

Test first

Miért?
A megrendelő az úr és ő határozza meg egy szolgáltatás formáját. Egy szerviz-implementáció csak akkor pontos, ha egy kliensen keresztül hajtják meg.

Ha a komponensorientáltság azt követeli meg, hogy a komponensek szerződéseit az implementálásuktól függetlenül határozzuk meg, akkor felmerül az a kérdés, hogyan is történjen ez. Kerekasztal-megbeszéléssel? Ez is biztosan egy módszer. De jobb módszer az, ha a szerződéseket nem tervezzük sokáig a táblánál, hanem azonnal kódba öntjük őket. Komponensszerződések – vagy általánosabban: minden kód interfész – végeredményben más kódoknak API-ként szolgálnak. Ezért konzekvens és hatékony ebből a kódból kiindulva interfészeket meghatározni.Ez a célja a Test firstnek. A Test first arra az ötletre épít, hogy a funkcionális egységeket (eljárásokat, osztályokat stb.) kliens-szerviz-viszony jellemez. Ezek a viszonyok a kliens és a szerviz közötti interfész körül forognak. És ezt az interfészt a kliensnek kellene meghatároznia. A kliens a szerviz megrendelőjeként úr. Őt kell szolgálja a szerviz, ehhez kelljen tehát igazodnia a szerviz interfészének.

Egy szoftver kódegységek interfészének meghatározása ebből az okból kifolyólag kintről befelé történik. Kint a felhasználói felületen ül a legvégső kliens, a felhasználó. Ő határozza meg az UI-kódegységek vizuális/tapintható interfészét. Ők azonban a lejjebb fekvő kódrétegek kliensei. Ezek aztán a mély rétegek kliensei stb. A legalsó kódrétegek teljesítményét és interfészét tehát csak akkor lehet meghatározni, amikor a fölöttük levőké már meg van határozva stb.

Ez ellent mond a kódegységek gyakori bottom-up meghatározás szerinti hozzáállásának. A projektek gyakran kérik egy adatelérési réteg meghatározását és implementálását. Ez érthető is, hiszen az ilyen alapvető funkcionalitás látszólag minden további dolog feltétele. De ez az eljárás problémás, mert sok kudarcba fulladt projekt azt mutatja, hogy:

  • Aki lentről felfelé, bentről kifelé specifikál és implementál, az a megrendelő túl későn tud egy értéket felajánlani. Ez legalábbis frusztráló, ha nem kontraproduktív.
  • Aki bottom-up jár el a specifikációban, az az ultimatív kliens, a felhasználó pontos követelményei nélkül specifikál. Amit tehát specifikál az belefut abba a veszélybe, hogy a végén túl általános és ezáltal kezelhetetlen – vagy akár használhatatlan lesz (a YAGNI szabály megszegése, lásd fent és a piros fokozaton).
  • Aki lentről felfelé implementál belefut abba a veszélybe, hogy nem szeparál valóban. Mert amikor szükség van mélyebb rétegekre ahhoz, hogy a fölöttük lévőket implementáljuk, akkor valószínűleg nem használunk elszigetelt unit teszteket álobjektumokkal és Inversion of Control-t sem.

A Clean Code fejlesztők azonban elkerülik ezeket a problémákat. Az interfészeket nem csak az implementációk előtt (Contract-first, lásd fent komponensorientáltság) specifikálják, hanem kintről befelé és egészen gyakorlatias kódolással. Az automatizált tesztek eszközével ugyanis nagyon egyszerű az interfészeket kis lépésekben tesztek formájában meghatározni.

A Test first a szintaktikai szerződésekhez (pl. interfészek) egy szemantikai oldalt ad hozzá. A szemantika specifikálásának más, formális eljárása hiányában a tesztek az egyetlen járható út a követelmények formalizálásához. Ha valaki egy fejlesztőhöz hozzá akar rendelni egy komponenst implementálásra, akkor az jobban teszi, ha nem csak a „felületét” (API) írja elő szintaktikailag, hanem a kívánt viselkedést is tesztek formájában.

Ennek sok előnye van:

  • Az interfész formája közvetlenül kliens-meghajtott, ezáltal maximálisan releváns. A YAGNI-nak nincsen esélye.
  • A tesztek nem csak tesztek, hanem specifikációdokumentációk. Egy interfész használói ugyanúgy tanulmányozhatják, mint az implementálói. Egy külön dokumentáció messzemenően szükségét veszti. Ez megfelel a DRY elvnek.
  • A specifikációk nem csak passzív szövegek, hanem végrehajtható kódok. Ha már egy implementáció rendelkezésre áll, ellenőrizni lehet a tesztekkel szemben. Így a specifikáció és a tesztek elkészítése nem időrabló egymásra következő fázisok. Ez emeli a produktivitást. Így a minőségbiztosítás megelőzi az implementációt.

Lásd még az eszközök alatt.

Published inPraktikák