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.

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.
Végezze el a TDD tesztet
A tesztvezérelt fejlesztés öt lépése

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.

Elfogadási TDD és Fejlesztői TDD

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

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.

Példa a TDD-re

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

Példa a TDD-re

A TestPassword ();

A kimenet ELFOGADVA, az alábbiak szerint;

teljesítmény:

Példa a TDD-re

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.

Példa a TDD-re

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):

Példa a TDD-re

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 ().

Példa a TDD-re

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.

Példa a TDD-re

output:

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

Példa a TDD-re

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.