Az ATDD elvei: Az egyszerű felelősség elve

Egy napon az ATDD-ről (Acceptance Test Driven Development: Átvételi Teszt Vezérelt Fejlesztés) beszélgettem Kishen Simbhoedatpanday-val , és felmerült egy lehetőség egy ATDD implementációs előadásra. Beszélgettünk a tesztek mérhetőségéről és hogy hogyan kellene a teszteket úgy újraszervezni, hogy még eredményesebbek legyenek. Gojko írt egyszer az elfogadási tesztek anatómiájáról és arra gondoltam, hogy sokkal tisztábban kellene fogalmaznunk ebben a kérdésben. Ez szöget ütött a fejembe. Az egyszerű felelősség elve szintén alkalmazható az automata eseteknél  és a miértek megértésénél. Koncepcionális szinten kell ezt átgondolni. Az üzleti- és alkalmazásszintű aggodalmak szintjén és sokszor a teszteszközök szintjén (gondoljunk a Seleniumra) borzasztó dolgok ezek. Hagyjuk ennek a kifejtését későbbre.

A probléma

Ez a példa jól mutatja ezt. Nézzük meg! Egy rövid Google-keresés után találtam:

Funkció:

Mint egyszerű felhasználó képes kell legyek egy gyors Google-keresés indítása.

Forgatókönyv az egyszerű Google-keresésre:

• A Google fő képernyőjén állok.
• Beírom a keresési mezőbe, hogy ATDD by example.
• Klikkelek a Keresés gombra.
• Megnyitom az első találatot
• Az oldalon látnom kell az ATDD by Example : A Practical Guide to Acceptance Test-Driven Development (Addison-Wesley Signature Series (Beck))” könyvet és leírását.

Mi a hibás ebben az esetben? Ha kicsit visszatekintünk a sorokra, a probléma abban rejlik, hogy ugyanabban a szövegleírásban több absztrakciós szint is megjelenik. Arra szeretnék rávilágítani, hogy különböző nézőpontokból lehet vizsgálni ugyanazt a dolgot.

Például, az a sor, ahol a keresési mezőt az ATDD by example-vel töltöm ki, értelmezhetem úgy, hogy a keresés domain-beli fogalmával foglalkozom, vagy a html oldal alkalmazási területével, vagy a böngésző driver könyvtárával. Hasonlóan a Klikkelek a Keresés gombra sornál, az alkalmazás szintjét, vagy az üzleti szintet is nézhetem. Az üzleti területen a gomb magát a keresést valósítja meg, míg az alkalmazás területén ez egy implementációs rész, ahol van egy gomb a keresésnek.

A probléma a különböző koncepciók keveréséből adódik, mely 3 tényezőn alapszik:

• Nehéz megírni
• Nehéz értelmezni
• Nehéz kezelni

Nehéz megírni

Várjunk csak! Miért? Úgy működik, ahogy az alkalmazás fut, ahogy implementálva lett, tehát egyszerű megírni, nem? Nem!

Őszintén mondom, nagyon sok ilyen tesztesetet írtam már életemben. Ezekről a szörnyű napokról rengeteg dologra emlékszem. Leginkább arra, hogy gyakran nagyon fáradtan értem haza. Rengeteg időt kellett azzal töltenem, hogy az összes lehetőséget számba vegyem. Ha a feladatot ezen a módon oldom majd meg, akkor az alkalmazás így és így fog majd működni és itt és itt lesz vele probléma.

Így most érthető? Nem valami jó a különböző leírásokat keverni. Ha a teszteket ezen elgondolás szerint írom meg, sokkal nehezebb dolgom van, mintha csak az üzleti szemlélet felől fognám meg a kérdést és tisztán azt az oldalt fejteném ki. Rengeteg dolgot kell egyszerre fejben tartanom mind az üzleti, mind pedig az alkalmazás oldaláról, sőt sokszor még a műszaki oldalról is.

Most összehasonlításképpen a példa másképpen:

Funkció:

Mint felhasználó képes kell, hogy legyek egy gyors Google-keresésre.

Forgatókönyv az egyszerű Google-keresésre:

• Keressünk az ATDD by example-re
• Aztán nézzük meg az egyik találatot az amazon.com-ról

Így világosabb? Lehet, hogy az. Milyen nehéz volt megírni ezt? Szerintem nem volt olyan nehéz. Nem kell emlékeznem a html-ek részleteire, arra, hogy hol volt a keresőmező, és hogy melyik gombot kellett ehhez megnyomni. Az üzleti oldalról közelítem meg a kérdést „keresek valamit” és várok legalább egyfajta eredményre. Teljesen egyértelmű a számomra.

De, de, de, de! Tudjuk ezt a tesztet egyszerűen rögzíteni? Jó kérdés! Gondoljunk arra, mi történik, ha a teszt 5 hónap múlva hibára fut.

Nehéz olvasni

Alapjában véve ugyanaz vonatkozik ide is, mint az írásra. Az érintett területeken rengeteg háttér-kapcsolódást kell észben tartani. A fenti példában legalább három területet számoltam össze az öt sorban. És ez csupán egy forgatókönyv, egy teszttel. A Te teszteset-halmazodban hány eset van?

Tehát egy nem fókuszált teszt nagyszerű példa erre, amikor olvasod és próbálod megtalálni mi is a probléma valójában. Az a teszt amelyik különböző területekkel dolgozik ugyanabban az időben, az egy fókuszálatlan teszt. Ilyenkor mindenképpen több terület koncepcióját kell egyszerre figyelembe venni és képesnek kell lenni a területek koncepciói közötti váltásokra. Olyan ez, mintha 3 story-t olvasnál egyszerre: üzletit, alkalmazásit és egy teszteszközöst.

Összehasonlítva a második példával már világosabb? Azt gondolom, hogy érthetőbb. Ha az üzleti területre fókuszálunk, akkor képesek leszünk e szerint gondolkodni. Ez megmagyarázza, hogy miért is szeretek unit teszteket írni az automatizálásban. Azért, mert meg így tudnom magyarázni, hogy ragadtam meg az alkalmazás tesztelését az automatizálás szempontjából. Biztosnak kell lennem abban, hogy mind a domain, mind a saját gondolkodásom szerint teszteltem az alkalmazást.

Nehéz kezelni

A legnagyobb fejfájást a hosszú távú karbantartás jelenti. Gondoljunk erre is! Ha különböző területek (üzleti, applikációs, technikai) alapján vizsgáljuk meg az aktuális feladatot, akkor a tesztelés mind a három területben meg kell, hogy történjen, mindet le kell fednie. Ha megváltoztatunk mondjuk egy technikai elemet, a teszt el fog szállni az összes területen. Ha megváltoztatjuk az alkalmazást a teszt el fog szállni ismételten, és ugyanígy fog tenni az üzleti logika változása esetén is. Ez így rengeteg karbantartási kérdést vet fel.

Ha ezen az úton haladunk, akkor egyazon időben különböző módon való gondolkodásra lesz szükségünk. Az üzleti tesztet példákból építjük fel, az alkalmazás tesztelése a rendszerteszttel együtt kell, hogy működjön, és így tovább. Természetesen a tesztcsapatnak is képesnek kell lennie a változásokat kezelni a tesztekben.

Három különböző domain, három különböző mód, ahogy kommunikálni kell a változásokat a tesztelés számára.

Ez a koncepció nem egy új koncepció a szoftverfejlesztésben. A legnehezebb része, azt észrevenni, hogy mikor keverjük a különböző megközelítéseket. Ennek eredménye, hogy a tesztek könnyebben érthetők lesznek, könnyebb lesz teszteket írni, olvasni, illetve karbantartani. Azt hiszem, most már világos, hogy ez a kis többletráfordítás mennyi energiát takarít meg a számunkra.

Látsz még egyéb problémát ebben a néhány soros példában? Meg tudsz még világítani egyszerű felelősségi veszélyeket az átvételi tesztekben? Abban kell fejlődnünk, hogy minél hatékonyabban megtaláljuk ezeket a veszélyeket.

Forrás: http://www.shino.de/2014/05/28/principles-of-atdd-single-responsibility-principle/
Szerző: Markus Gärtner