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,
- Adjon hozzá egy tesztet.
- Futtassa le az összes tesztet, és ellenőrizze, hogy valamelyik új teszt sikertelen-e.
- Írj valami kódot.
- Futtasson teszteket és Refaktor kódot.
- Ismétlés.
TDD ciklus határozza meg
- Írj tesztet
- Tedd futni.
- Változtassa meg a kódot, hogy helyes legyen, azaz Refaktor.
- 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
- 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).
- 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.
- 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.
- 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
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.