Mi a TDD és az ATDD?

Ez a cikk a két népszerű tesztelési módszer, a TDD és az ATDD közötti hasonlóságokat és különbségeket mutatja be.

A TDD a tesztvezérelt fejlesztés, míg az ATDD az elfogadási tesztek által vezérelt fejlesztés rövidítése. E két tesztelési megközelítés működésének megértése kritikus fontosságú a teszteléssel foglalkozó szakemberek számára, és ez a bejegyzés egy alapozó lesz, amely hozzásegíti Önt mindkettő felfedezéséhez. Meg fogja érteni a TDD vs ATDD-t.

Mi a tesztvezérelt fejlesztés (TDD)?

A TDD az extrém programozás (XP) elveit követő szoftverfejlesztési rendszer, azonban idővel önálló szoftverfejlesztési technikaként vált önállóvá.

A TDD-ben az egységtesztelés közvetlenül a forráskódon történik.

Először a tesztelő ír egy automatizált tesztesetet, amely meghatározza azt a kívánt funkciót, amelyet a rendszernek ideális esetben teljesítenie kellene, de szándékosan úgy tervezi meg a tesztesetet, hogy azt a rendszer jelen állapotában nem tudja teljesíteni.

Második lépésben a fejlesztő feljegyzi az okokat, amelyek miatt a rendszer nem teljesítette a tesztet, és megírja a rendszer refaktorálásához szükséges kódot, hogy az a második próbálkozásnál átmenjen a teszten. Ezt a folyamatot az alábbi ábra foglalja össze.

A TDD-folyamat így folytatódik, cikcakkban haladva a kudarc és a siker között, úgy, hogy minden egyes iteráció a rendszert a határai közé szorítja, majd a keletkező visszajelzéseken keresztül segít a rendszer túljutásában.

A TDD egy kísérlet az önkéntes kudarcra, és nem kevés bátorság kell ahhoz, hogy az ember felfogja ezt az intuitív technikát. Azonban ha egyszer sikerül, akkor egy egyszerű, mégis rendkívül hatékony módszerrel jutalmazzák, amellyel a tesztelés során leküzdheti a kudarctól való félelmet, miközben javíthat a munkáján.

Mi az elfogadási tesztvezérelt fejlesztés (ATDD)?

Az ATDD egy olyan együttműködő tesztelési módszer, amely az új szoftver létrehozásában részt vevő összes embert (pl.pl. tesztelők, fejlesztők és felhasználók), hogy csapatként határozzák meg azokat az elfogadási kritériumokat, amelyeket a rendszernek a fejlesztés korai szakaszában teljesítenie kell.

Ez a lépés azt hivatott biztosítani, hogy az érintettek egyetértsenek a projekt fő céljaiban, különösen a végfelhasználó által elvárható funkcionalitás tekintetében. Az ATDD ezen szakaszában az olyan technikák, mint a felhasználói személyképek és a felhasználói történetek nagyon hasznosak lehetnek.

Amikor az elfogadási teszteket végül lefuttatják a rendszeren, a hibákat megjegyzik, majd a fejlesztők refaktorálják a hibás komponenseket, megírva a következő próbálkozáskor az elfogadási kritériumok teljesítéséhez szükséges kódot.

Ezt a folyamatot iteratív módon végzik, általában minden sprint végén, amíg a végtermék készen nem áll a telepítésre. Az alábbi ábra ezt magyarázza.

Az ATDD világosabb képet ad a csapatnak arról, hogyan fog működni a végtermék, így mindenki a hosszú távú célokra koncentrálhat, ahelyett, hogy elveszne az egyes kódsorokban.

Összefoglalva

Most már jól érti a TDD és az ATDD közötti alapvető különbségeket. Ez a két tesztelési módszer szorosan kapcsolódik egymáshoz, azonban az ATDD az elfogadási tesztelést is bevonja a folyamatba, és nagyobb hangsúlyt fektet a csoportos együttműködésre, mint a TDD.

Mindkét megközelítés jól illeszkedik az agilis elvekhez, mivel mindkettő a visszajelzések gyűjtésére ösztönöz, hogy a korábbi hibáinkra építhessünk. Miközben folyamatosan refaktorálod a rendszert és kezeled az előző próbálkozás során felmerült problémákat, ezek a módszerek segítenek egy értékesebb végtermék inkrementális módon történő kifejlesztésében.

Jelentkezz 60,000+ előfizetőhöz

A legújabb blogokért, iparági frissítésekért és exkluzív tippekért.

*Az e-mail címed biztonságban van nálunk, mi is utáljuk a spameket