Ha ismered a TDD-t, akkor az ATDD valahogy a TDD magasabb szintű teszteléssel és több érintett bevonásával, más szóval inkább elfogadási tesztelés, mint egységtesztelés. Ha többet szeretne megtudni a TDD-ről, akkor kérjük, olvassa el az alábbi bejegyzést:
Az ATDD (acceptance test-driven development) egy olyan fejlesztési módszertan, amely az üzleti ügyfelek, a fejlesztők és a tesztelők közötti kommunikáción alapul. Az ATDD számos olyan gyakorlatot foglal magában, mint a példával történő specifikáció, a viselkedésvezérelt fejlesztés (BDD), a példaorientált fejlesztés (EDD) és a támogatásvezérelt fejlesztés, más néven történet tesztvezérelt fejlesztés (SDD). Mindezek az eljárások segítik a fejlesztőket és a tesztelőket abban, hogy a megvalósítás előtt megértsék az ügyfél igényeit, és lehetővé teszik, hogy az ügyfelek a saját szakterületük nyelvén beszélgethessenek.
Az agilis csapatokban széles körben alkalmazott ATDD olyan gyakorlat, amelyben az üzleti elemzők, fejlesztők ,tesztelők és a felhasználók együtt dolgoznak az egyes történetek (vagy funkciók) elfogadási kritériumainak meghatározásán a fejlesztési folyamat korai szakaszában (a kódolás megkezdése előtt). Ez a megközelítés lehetővé teszi, hogy az összes érdekelt fél azonos szintű elvárt eredményekkel rendelkezzen és azokat fenntartsa, mielőtt bármelyik fejlesztő elkezdené a kódolást.
Tudom, hogy mindannyian hallottuk már ezt a sztereotípiát: “A fejlesztőket nem érdekli a specifikáció, a tesztelők pedig nem akarnak automatizálni”, de az ATDD-vel ez rengeteg elvesztegetett időt és pénzt takarít meg azáltal, hogy a fejlesztők jobban részt vesznek a specifikáció korai szakaszában, a tesztelők pedig automatizálják az elfogadási teszteket.
Hogyan valósul meg az ATDD a “való életben”?
A SCRUM-ot használja? Ha igen, akkor a munka nagy részét már az ATDD-ben végzi. ha nem, akkor a következő példa táplálja a kíváncsiságát :
Példa
Tegyük fel, hogy a terméktulajdonos vagy az ügyfél a következő funkciót kérte a mobil alkalmazásunkban: “Miután ezt a kérést az egész csapattal (üzleti elemző, fejlesztők, tesztelők…) áttekintettük, és további részleteket adtunk a történethez vagy a funkcióhoz, lesz néhány ehhez hasonló “elfogadási” vagy “funkcionális” tesztünk (Kérjük, vegye figyelembe, hogy ez csak egy példa, sok elfogadási teszt hiányzik ehhez a funkcióhoz):
- Akceptance Criteria 1: Az alkalmazás opcionálisan elfogadja a bejelentkezést/jelszót a bejelentkezéshez
- Acceptance Criteria 2: A gomb megkerülésével a felhasználó bejelentkezés nélkül böngészhet az alkalmazáson belül.
- Akceptációs kritériumok 3: A gomb megkerülés kiválasztásakor az alkalmazás nem tárol és nem jelenít meg semmilyen felhasználó-specifikus információt.
- Akceptációs kritériumok 4: A bejelentkezés/jelszó használata esetén az alkalmazás felhasználói felületét a felhasználó beállításaihoz kell igazítani.
Enyereségek
1- Ügyfél-eladó összehangolása : Azáltal, hogy a fenti elfogadási kritériumok bemeneti információként szerepelnek, most már biztosak vagyunk (minden csapattag) abban, hogy az alkalmazás megtartja a bejelentkezés/jelszó funkcióját, és csak egy gombot ad hozzá, amely lehetővé teszi a felhasználó számára a bejelentkezési képernyő megkerülését.
2- Minőség és költséghatékonyság: A fenti tesztek könnyen automatizálhatók, még mielőtt a fejlesztők elkezdenék a kódolást.
3- Time to Market: A tesztek implementálása után a fejlesztők még a bejelentés előtt validálhatják a szükséges feladatokat.
Az ATDD nem igényel speciális eszközöket. Fontos tudni, hogy NEM minden elfogadási tesztet kell automatizálni. A tesztek automatizálása több szemponttól függ, mint például: technikai kihívások, határidő és költségek.
Szerűen ajánlott eszközök?
Az ATDD nem igényel semmilyen konkrét eszközt. Fontos tudni, hogy NEM minden átvételi tesztet kell automatizálni. A tesztek automatizálása több szemponttól függ, mint például: technikai kihívások, határidő és költségek.
Ezzel a résszel csak egy áttekintést adok az ATDD-nél leggyakrabban használt automatizálási eszközökről:
FitNess: A teljesen integrált önálló wiki és elfogadási tesztelési keretrendszer
Robot keretrendszer: Általános teszt automatizálási keretrendszer az elfogadási teszteléshez és az elfogadási tesztvezérelt fejlesztéshez (ATDD)
Calabash: Automatizált elfogadási tesztelés mobilalkalmazásokhoz – Vegye figyelembe, hogy ez a keretrendszer nem feltétlenül támogatja a legújabb operációs rendszer verziót (Android O felett )