Mi az a tesztvezérelt fejlesztés (TDD)? Példa

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

Tesztvezérelt fejlesztés (TDD) egy olyan szoftverfejlesztési megközelítés, amelyben teszteseteket fejlesztenek ki annak meghatározására és érvényesítésére, hogy a kód mit fog tenni. Egyszerűen fogalmazva, először minden egyes funkcióhoz teszteseteket készítenek és tesztelnek, és ha a teszt sikertelen, akkor az új kódot írják, hogy átmenjen a teszten, és a kód egyszerű és hibamentes legyen.

A tesztvezérelt fejlesztés a tesztek tervezésével és fejlesztésével kezdődik egy alkalmazás minden kis funkciójához. A TDD keretrendszer arra utasítja a fejlesztőket, hogy csak akkor írjanak új kódot, ha az automatizált teszt sikertelen. Ezzel elkerülhető a kód megkettőzése. A TDD teljes formája tesztvezérelt fejlesztés.

A TDD egyszerű koncepciója az, hogy új kód írása előtt (a fejlesztés előtt) megírja és javítja a sikertelen teszteket. Ez segít elkerülni a kód megkettőzését, mivel egyszerre csak kis mennyiségű kódot írunk, hogy átmenjünk a teszteken. (A tesztek nem más, mint követelményfeltételek, amelyeket tesztelnünk kell a teljesítéshez).

A tesztvezérelt fejlesztés egy automatizált teszt fejlesztésének és futtatásának folyamata az alkalmazás tényleges fejlesztése előtt. Ezért a TDD-t néha más néven is hívják Az első fejlesztés tesztelése.

Hogyan kell elvégezni a TDD tesztet

A következő lépések határozzák meg a TDD teszt végrehajtásának módját,

1. Adjon hozzá egy tesztet.
2. Futtassa le az összes tesztet, és ellenőrizze, hogy valamelyik új teszt sikertelen-e.
3. Írj valami kódot.
4. Futtasson teszteket és Refaktor kódot.
5. Ismétlés.

TDD ciklus határozza meg

1. Írj tesztet
2. Tedd futni.
3. Változtassa meg a kódot, hogy helyes legyen, azaz Refaktor.
4. Ismételje meg a folyamatot.

Néhány pontosítás a TDD-vel kapcsolatban:

• A TDD megközelítés sem a „tesztelésről”, sem a „tervezésről” nem szól.
• A TDD nem azt jelenti, hogy „írj meg néhány tesztet, majd építs egy olyan rendszert, amely megfelel a teszteknek.
• A TDD nem azt jelenti, hogy „végezzen sok tesztelést”.

TDD vs. Hagyományos tesztelés

Az alábbiakban bemutatjuk a fő különbséget a tesztvezérelt fejlesztés és a hagyományos tesztelés között:

A TDD megközelítés elsősorban egy specifikációs technika. Ez biztosítja, hogy a forráskódot alaposan teszteljék megerősítő szinten.

• A hagyományos teszteléssel a sikeres teszt egy vagy több hibát talál. Ugyanaz, mint a TDD. Ha egy teszt sikertelen, akkor előrehaladást ért el, mert tudja, hogy meg kell oldania a problémát.
• A TDD biztosítja, hogy a rendszer valóban megfelel a számára meghatározott követelményeknek. Segít építeni a rendszerbe vetett bizalmát.
• A TDD-ben nagyobb hangsúlyt fektetnek az éles kódra, amely ellenőrzi, hogy a tesztelés megfelelően működik-e. A hagyományos tesztelés során nagyobb hangsúlyt fektetnek a tesztesetek tervezésére. A teszt megmutatja-e az alkalmazás megfelelő/nem megfelelő végrehajtását a követelmények teljesítése érdekében.
• A TDD-ben 100%-os lefedettségi tesztet ér el. A hagyományos teszteléssel ellentétben minden kódsort tesztelnek.
• A hagyományos tesztelés és a TDD kombinációja a rendszer tesztelésének fontosságához vezet, nem pedig a rendszer tökéletesítéséhez.
• In Agilis modellezés (AM), érdemes „céllal tesztelni”. Tudnia kell, hogy miért tesztel valamit, és milyen szinten kell azt tesztelni.

Mi az elfogadási TDD és a fejlesztői TDD

A TDD-nek két szintje van

1. Elfogadási TDD (ATDD): Az ATDD-vel egyetlen átvételi tesztet írsz. Ez a teszt teljesíti a specifikáció követelményeit, vagy kielégíti a rendszer viselkedését. Ezután írjon csak annyi termelési/funkcionalitási kódot, hogy teljesítse az elfogadási tesztet. Az elfogadási teszt a rendszer általános viselkedésére összpontosít. Az ATDD-t más néven is ismerték Viselkedésvezérelt fejlesztés (BDD).
2. Fejlesztői TDD: A Developer TDD-vel egyetlen fejlesztői tesztet ír, azaz egységtesztet, majd csak annyi gyártási kódot, hogy teljesítse ezt a tesztet. Az egységteszt a rendszer minden apró funkciójára összpontosít. A fejlesztői TDD-t egyszerűen csak úgy hívják TDD.Az ATDD és a TDD fő célja, hogy részletes, végrehajtható követelményeket határozzon meg a megoldáshoz a just in time (JIT) alapon. A JIT azt jelenti, hogy csak azokat a követelményeket veszik figyelembe, amelyekre a rendszerben szükség van. Tehát növelje a hatékonyságot.

TDD skálázása az Agile Model Driven Development (AMDD) segítségével

A TDD nagyon jó a részletes specifikációban és érvényesítésben. Nem képes átgondolni a nagyobb problémákat, mint például az általános tervezés, a rendszer használata vagy a felhasználói felület. Az AMDD megoldja azokat az Agilis skálázási problémákat, amelyeket a TDD nem.

Így az AMDD nagyobb problémákra használt.

Az AMDD életciklusa

A modellvezérelt fejlesztésben (MDD) kiterjedt modellek jönnek létre a forráskód írása előtt. Amelyiknek viszont agilis megközelítése van?

A fenti ábrán minden doboz egy fejlesztési tevékenységet jelez.

Az elképzelés a projekt első hetében végrehajtandó előrejelzési/elképzelési tesztek egyik TDD-folyamata. Az elképzelés fő célja a rendszer hatókörének és a rendszer architektúrájának azonosítása. Magas szintű követelményeket és architektúra modellezést végeznek a sikeres vizionálás érdekében.

Ez az a folyamat, ahol nem a szoftver/rendszer részletes specifikációja készül, hanem a szoftver/rendszer követelményeinek feltárása határozza meg a projekt átfogó stratégiáját.

0. iteráció: Elképzelés

Két fő alaktiválás van.

1. A kezdeti követelmények elképzelése.A magas szintű követelmények és a rendszer hatókörének azonosítása több napig is eltarthat. A fő hangsúly a használati modell, a kezdeti tartománymodell és a felhasználói felület modelljének (UI) feltárásán van.
2. Kezdeti Architekturális vizionálás. A rendszer architektúrájának azonosítása is több napot vesz igénybe. Lehetővé teszi a projekt műszaki irányainak meghatározását. A fő hangsúly a technológiai diagramok, a felhasználói felület (UI) folyamatának, a tartománymodellek és a változási esetek feltárásán van.

Iterációs modellezés

Itt a csapatnak meg kell terveznie az egyes iterációkhoz elvégzendő munkát.

• Minden iterációhoz agilis folyamatot használunk, azaz minden iteráció során új munkaelem kerül hozzáadásra prioritással.
• Először a magasabb prioritású munkát veszik figyelembe. A hozzáadott munkaelemek bármikor átállíthatók, vagy eltávolíthatók az elemek halmazából.
• A csapat megbeszéli, hogyan fogják megvalósítani az egyes követelményeket. Erre a célra a modellezést használják.
• Modellezési elemzést és tervezést végeznek minden olyan követelményhez, amelyet az adott iterációhoz alkalmazni fognak.

Modellvihar

Ezt Just in time modellezésnek is nevezik.

• Itt a modellezési munkamenet egy 2/3 tagú csapat vesz részt, akik papíron vagy táblán vitatják meg a kérdéseket.
• A csapat egyik tagja megkér egy másikat, hogy modellezzen velük. Ez a modellezés körülbelül 5-10 percet vesz igénybe. Ahol a csapat tagjai összegyűlnek, hogy megosszák a táblát/papírt.
• Addig vizsgálják a problémákat, amíg meg nem találják a probléma fő okát. Éppen időben, ha az egyik csapattag felismeri a problémát, amelyet meg akar oldani, akkor gyors segítséget kér a többi csapattagtól.
• Ezután a csoport többi tagja megvizsgálja a problémát, majd mindenki folytatja a korábbiak szerint. Stand-up modellezésnek vagy ügyfél-minőségbiztosítási munkamenetnek is nevezik.

Tesztvezérelt fejlesztés (TDD)

• Elősegíti az alkalmazáskód és a részletes specifikáció megerősítő tesztelését.
• Mind az elfogadási teszt (részletes követelmények), mind a fejlesztői tesztek (egységteszt) a TDD bemenetei.
• A TDD egyszerűbbé és áttekinthetőbbé teszi a kódot. Lehetővé teszi a fejlesztő számára, hogy kevesebb dokumentációt tartson fenn.

Reviews

• Ez nem kötelező. Tartalmazza a kódellenőrzéseket és a modellellenőrzéseket.
• Ez megtehető minden iterációra vagy az egész projektre.
• Ez egy jó lehetőség a projekttel kapcsolatos visszajelzések küldésére.

Tesztvezérelt fejlesztés (TDD) vs. Agilis modellvezérelt fejlesztés (AMDD)

TDD	AMDD
A TDD lerövidíti a programozási visszacsatolási hurkot	Az AMDD lerövidíti a modellezési visszacsatolási hurkot.
A TDD egy részletes specifikáció	Az AMDD nagyobb problémák esetén működik
A TDD elősegíti a jó minőségű kód fejlesztését	Az AMDD az érdekelt felekkel és a fejlesztőkkel való kiváló minőségű kommunikációt támogatja.
A TDD a programozókhoz beszél	AMDD beszél vele Business Analyst, érdekelt felek és adatszakértők.
TDD nem vizuálisan orientált	AMDD vizuálisan orientált
A TDD korlátozott hatókörrel rendelkezik a szoftveres munkákra	Az AMDD széles hatókörrel rendelkezik, beleértve az érdekelt feleket is. Ez magában foglalja a közös megegyezés elérésére irányuló munkát
Mindkettő támogatja az evolúciós fejlődést	---------------

TDD keretrendszerek

Itt található a legjobb tesztvezérelt fejlesztési (TDD) keretrendszerek listája

1. Junit
2. TestNG
3. csUnit és NUnit
4. Rspec

Most pedig tanuljuk meg a tesztvezérelt fejlesztést példán keresztül.

Példa a TDD-re

Ebben a tesztvezérelt fejlesztési példában osztályjelszót fogunk meghatározni. Ezen az órán igyekszünk a következő feltételeket teljesíteni.

A jelszó elfogadásának feltétele:

• A jelszónak 5 és 10 karakter között kell lennie.

Ebben a TDD-példában először azt a kódot írjuk, amely megfelel a fenti követelményeknek.

1 forgatókönyv: A teszt futtatásához létrehozzuk a PasswordValidator osztályt ();

A TestPassword ();

A kimenet ELFOGADVA, az alábbiak szerint;

teljesítmény:

2 forgatókönyv: Itt láthatjuk, hogy a TestPasswordLength () metódusban nincs szükség a PasswordValidator osztály példányának létrehozására. A példány azt jelenti, hogy létrehoz egy tárgy osztályból az adott osztály tagjaira (változóira/módszereire) hivatkozni.

Eltávolítjuk a kódból a PasswordValidator pv = new PasswordValidator () osztályt. Hívhatjuk a érvényes () módszer közvetlenül általa PasswordValidator. Érvényes („Abc123”). (Lásd a képet lent)

Tehát az alábbiak szerint refaktoráljuk (módosítjuk a kódot):

3 forgatókönyv: Az újrafaktorálás után a kimenet sikertelen állapotot mutat (lásd az alábbi képet), ez azért van, mert eltávolítottuk a példányt. Tehát nincs utalás nem statikus módszerre érvényes ().

Tehát meg kell változtatnunk ezt a módszert úgy, hogy „static” szót adunk a Boolean elé, mint nyilvános statikus logikai érték isValid (String jelszó). A Class PasswordValidator () újrafaktorálása a fenti hiba eltávolításához a teszt sikeres teljesítéséhez.

output:

A PassValidator () osztály módosítása után, ha lefuttatjuk a tesztet, akkor a kimenet PASSED lesz az alábbiak szerint.

A TDD előnyei

Az alábbiakban felsoroljuk a tesztvezérelt fejlesztés fő előnyeit a szoftverfejlesztésben:

Korai hibaértesítés.

• A fejlesztők tesztelik a kódjukat, de az adatbázis-világban ez gyakran kézi tesztekből vagy egyszeri szkriptekből áll. A TDD használatával idővel egy automatizált tesztcsomagot hoz létre, amelyet Ön és bármely más fejlesztő tetszés szerint újra lefuttathat.

Jobban megtervezett, tisztább és jobban bővíthető kód.

• Segít megérteni, hogyan fogják használni a kódot, és hogyan működik együtt más modulokkal.
• Ez jobb tervezési döntést és karbantarthatóbb kódot eredményez.
• A TDD lehetővé teszi kisebb kódok írását egyetlen felelősséggel, nem pedig több felelősségű monolitikus eljárásokat. Ez megkönnyíti a kód megértését.
• A TDD arra is kényszeríti, hogy csak a gyártási kódot írjon a felhasználói követelmények alapján történő tesztek teljesítéséhez.

Bizalom a Refaktor felé

• Ha a kódot refaktorálja, előfordulhat, hogy megtörik a kódot. Így egy sor automatikus teszttel kijavíthatja ezeket a szüneteket a kiadás előtt. Megfelelő figyelmeztetést kapunk, ha az automatizált tesztek használatakor szüneteket találunk.
• A TDD használata gyorsabb, bővíthetőbb kódot eredményez, kevesebb hibával, amely minimális kockázattal frissíthető.

Jó a csapatmunkához

• Csapattag hiányában a többi csapattag könnyen felveheti és dolgozhat rajta a kódon. Segíti a tudásmegosztást is, ezáltal összességében hatékonyabbá teszi a csapatot.

Jó a fejlesztőknek

• Bár a fejlesztőknek több időt kell tölteniük a TDD tesztesetek megírásával, sokkal kevesebb időt vesz igénybe a hibakeresés és az új funkciók fejlesztése. Tisztább, kevésbé bonyolult kódot fog írni.

Összegzésként

• A TDD a tesztvezérelt fejlesztés rövidítése.
• TDD jelentése: A kód módosításának folyamata annak érdekében, hogy megfeleljen egy korábban tervezett tesztnek.
• Nagyobb hangsúlyt fektet a gyártási kódra, nem pedig a teszteset tervezésére.
• A tesztvezérelt fejlesztés a kód módosításának folyamata annak érdekében, hogy megfeleljen egy korábban tervezett tesztnek.
• In Szoftverfejlesztés, Néha úgy is ismerik „Test First Development.”
• A TDD tesztelés magában foglalja a kód újrafaktorizálását, azaz bizonyos mennyiségű kód módosítását/hozzáadását a meglévő kódhoz anélkül, hogy a kód viselkedését befolyásolná.
• A TDD programozás használatakor a kód világosabbá és könnyebben érthetőbbé válik.