Tesztvezérelt fejlesztés
A tesztvezérelt fejlesztés (TDD) egy szoftverfejlesztési megközelítés, amelyben teszteseteket dolgoznak ki annak meghatározására és érvényesítésére, hogy a kód mit fog tenni. Egyszerűbben fogalmazva, az egyes funkciók teszteseteit először létrehozzák és tesztelik, és ha a teszt nem sikerül, akkor az új kódot megírják annak érdekében, hogy sikeres legyen a teszt, és a kód egyszerű és hibamentes legyen.
A tesztvezérelt fejlesztés az alkalmazások minden apró funkciójának tesztjeinek megtervezésével és fejlesztésével kezdődik. A TDD arra utasítja a fejlesztőket, hogy csak akkor írjanak új kódot, ha az automatizált teszt nem sikerült. Ezzel elkerülhető a kód duplikálása. A TDD teljes formája tesztvezérelt fejlesztés.
A TDD egyszerű koncepciója: a sikertelen tesztek kiírása és kijavítása az új kód írása előtt (a fejlesztés előtt). Ez segít elkerülni a kód megismétlődését, mivel egyszerre kis mennyiségű kódot írunk a tesztek teljesítése érdekében. (A tesztek nem más, mint követelményfeltételek, amelyeket tesztelnünk kell a teljesítésük érdekében).
A tesztvezérelt fejlesztés az automatizált teszt fejlesztésének és futtatásának folyamata az alkalmazás tényleges fejlesztése előtt. Ezért a TDD néha Test First Development néven is hívta .
Ebben az oktatóanyagban többet megtudhat-
- Hogyan kell elvégezni a TDD tesztet
- TDD vs. Hagyományos tesztelés
- Mi az elfogadási TDD és a Developer TDD
- A TDD méretezése agilis modellvezérelt fejlesztéssel (AMDD)
- Tesztvezérelt fejlesztés (TDD) vs. Agilis modellalapú fejlesztés (AMDD)
- Példa a TDD-re
- A TDD előnyei
Hogyan kell elvégezni a TDD tesztet
A következő lépések meghatározzák, hogyan kell elvégezni a TDD tesztet,
- Tegyen hozzá egy tesztet.
- Futtassa az összes tesztet, és nézze meg, nem sikerül-e új teszt
- Írj néhány kódot.
- Futtasson teszteket és Refactor kódot.
- Ismétlés.
A TDD ciklus meghatározza
- Írj tesztet
- Futtassa.
- Változtassa meg a kódot, hogy megfelelő legyen, azaz Refactor.
- Ismételje meg a folyamatot.
Néhány pontosítás a TDD-vel kapcsolatban:
- A TDD nem a "tesztelésről" és a "tervezésről" sem szól.
- A TDD nem azt jelenti, hogy "írjon néhány tesztet, majd hozzon létre egy olyan rendszert, amely megfelel a teszteknek.
- A TDD nem azt jelenti, hogy "végezzen sok tesztet".
TDD vs. Hagyományos tesztelés
A TDD megközelítés elsősorban specifikációs technika. Biztosítja a forráskód alapos tesztelését megerősítő szinten.
- A hagyományos teszteléssel a sikeres teszt egy vagy több hibát talál. Ez megegyezik a TDD-vel. Ha egy teszt kudarcot vall, akkor előrehaladt, mert tudja, hogy meg kell oldania a problémát.
- A TDD biztosítja, hogy rendszere valóban megfeleljen a rá meghatározott követelményeknek. Segít a rendszer iránti bizalom növelésében.
- A TDD-ben nagyobb hangsúlyt fektetnek a gyártási 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. Minden egyes kódsort tesztelnek, ellentétben a hagyományos teszteléssel.
- 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életességéhez.
- Az agilis modellezésben (AM) "céllal kell tesztelnie". Tudnia kell, miért tesztel valamit, és milyen szinten kell tesztelni.
Mi az elfogadási TDD és a Developer TDD
A TDD-nek két szintje van
- Acceptance TDD (ATDD): Az ATDD-vel egyetlen elfogadási tesztet írsz. Ez a teszt megfelel a specifikáció követelményeinek vagy kielégíti a rendszer viselkedését. Ezután írjon csak annyi gyártá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 Behavioral Driven Development (BDD) néven is ismerték .
- Fejlesztői TDD: A Fejlesztői 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 TDD-nek hívják .
Az ATDD és a TDD fő célja a megoldás részletes, végrehajtható követelményeinek pontos meghatározása a megfelelő időben (JIT). A JIT azt jelenti, hogy csak azokat a követelményeket vesszük figyelembe, amelyekre a rendszerben szükség van. Tehát növelje a hatékonyságot.
A TDD méretezése agilis modellvezérelt fejlesztéssel (AMDD)
A TDD nagyon jó a részletes specifikációban és validálásban. Nem sikerül átgondolni a nagyobb kérdéseket, mint például az általános tervezés, a rendszer használata vagy a felhasználói felület. Az AMDD az Agile skálázás problémáival foglalkozik, amelyeket a TDD nem.
Így az AMDD nagyobb kérdésekre használt.
Az AMDD életciklusa.
A modell-vezérelt fejlesztésben (MDD) kiterjedt modelleket hoznak létre a forráskód írása előtt. Melyek viszont agilis megközelítéssel rendelkeznek?
A fenti ábrán minden doboz egy fejlesztési tevékenységet ábrázol.
Az elképzelés az egyik TDD-folyamat, amely előre jelzi / elképzeli a teszteket, amelyet a projekt első hetében hajtanak végre. Az elképzelés fő célja a rendszer hatókörének és a rendszer architektúrájának azonosítása. A sikeres elképzelés érdekében magas szintű követelményeket és architektúra modellezést végeznek.
Ez az a folyamat, ahol nem a szoftver / rendszer részletes specifikációja történik, hanem a szoftver / rendszer követelményeinek feltárása határozza meg a projekt átfogó stratégiáját.
- 0. iteráció: Képzelet
Két fő alaktiválás létezik.
- A kezdeti követelmények elképzelése.
A rendszer magas szintű követelményeinek és alkalmazási körének meghatározása több napig is eltarthat. A fő hangsúly a használati modell, a kezdeti tartományi modell és a felhasználói felület modelljének (UI) feltárása.
- Kezdeti építészeti elképzelé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), a tartományi modellek és a Változás esetek feltárása.
- Iterációs modellezés:
Itt a csapatnak meg kell terveznie az egyes iterációknál elvégzendő munkát.
- Az egyes iterációkhoz agilis folyamatot használnak, azaz minden iteráció során új munkaelem kerül prioritással hozzáadásra.
- Az első, kiemelten kezelt munkát figyelembe vesszük. A hozzáadott munkaelemeket bármikor újrarendezheti vagy eltávolíthatja az elemekből.
- A csapat megbeszéli, hogyan fogják végrehajtani az egyes követelményeket. Erre a célra a modellezést használják.
- A modellezés elemzését és tervezését minden olyan követelmény esetében elvégezzük, amelyet az adott iteráció során megvalósítunk.
- Modell vihar:
Ez más néven Just in time Modeling.
- Itt a modellezési munkamenetben 2/3 tagú csapat vesz részt, akik papíron vagy táblán vitatják meg a kérdéseket.
- Az egyik csapattag megkéri a másikat, hogy készítsen modellt 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 kérdéseket, amíg nem találják meg a probléma fő okát. Épp időben, ha az egyik csapattag azonosítja a problémát, amelyet meg akar oldani, akkor gyorsan segítséget fog igénybe venni a csapat többi tagjával.
- Ezután a csoport többi tagja feltárja a kérdést, majd mindenki folytatja a továbbiakban. Stand-up modellezésnek vagy ügyfél QA munkamenetnek is nevezik.
- Tesztvezérelt fejlesztés (TDD).
- Elősegíti az alkalmazási kód megerősítő tesztelését és a részletes specifikációt.
- Mind az elfogadási teszt (részletes követelmények), mind a fejlesztői tesztek (egység teszt) a TDD bemenetei.
- A TDD egyszerűbbé és egyértelműbbé teszi a kódot. Ez lehetővé teszi a fejlesztő számára, hogy kevesebb dokumentációt tároljon.
- Vélemények.
- Ez nem kötelező. Ez magában foglalja a kódellenőrzéseket és a modellek felülvizsgálatát.
- Ez megtehető minden egyes iterációra vagy az egész projektre.
- Ez jó lehetőség arra, hogy visszajelzést adjon a projekthez.
Tesztvezérelt fejlesztés (TDD) vs. Agilis modellalapú fejlesztés (AMDD)
| TDD | AMDD |
|
|
|
|
|
|
|
|
|
|
|
|
| -------------------------------------------- |
Példa a TDD-re
Ebben a példában meghatározzuk az osztály jelszavát. Ehhez az osztályhoz megpróbáljuk kielégíteni a következő feltételeket.
A jelszó elfogadásának feltétele:
- A jelszónak 5-10 karakter között kell lennie.
Először azt a kódot írjuk meg, amely megfelel a fenti követelményeknek.
1. forgatókönyv : A teszt futtatásához létrehozzuk a PasswordValidator () osztályt;
A TestPassword () osztály felett fogunk futni;
A kimenet átmegy az alábbiak szerint;
Kimenet :
2. forgatókönyv : Itt láthatjuk a TestPasswordLength () metódusban, hogy nincs szükség a PasswordValidator osztály példányának létrehozására. A példány egy osztály objektum létrehozását jelenti az osztály tagjainak (változók / módszerek) hivatkozására.
Eltávolítjuk a PasswordValidator pv = new PasswordValidator () osztályt a kódból. Az isValid () metódust közvetlenül a PasswordValidator segítségével hívhatjuk meg . IsValid ("Abc123") . (Lásd az alábbi képet)
Tehát az alábbiak szerint refraktorozzuk (módosítsuk a kódot):
3. forgatókönyv : Miután a kimenet visszafejlesztése hibás á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 a nem statikus módszerre isValid ().
Tehát meg kell változtatnunk ezt a módszert úgy, hogy a "statikus" szót hozzáadjuk a Boolean elé, mivel a nyilvános statikus logikai isValid (karakterlánc jelszó). A Class PasswordValidator () átalakítása a fenti hiba kiküszöbölése érdekében, hogy sikeres legyen a teszt.
Kimenet:
Miután végrehajtottuk a tesztet a PassValidator () osztályon, ha lefuttatjuk a tesztet, akkor a kimenet átmegy az alábbiak szerint.
A TDD előnyei
- Korai hibaüzenet.
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 felépít egy automatizált tesztcsomagot, amelyet Ön és bármely más fejlesztő tetszés szerint újra futtathat.
- Jobb tervezésű, tisztább és bővíthetőbb kód.
- Segít megérteni, hogyan fogják használni a kódot, és hogyan lép kölcsönhatásba más modulokkal.
- Jobb tervezési döntést és karbantarthatóbb kódot eredményez.
- A TDD lehetővé teszi a kisebb kódok írását, amelyek egyetlen felelősséggel bírnak, nem pedig a több felelősséggel járó monolit eljárások. Ez megkönnyíti a kód megértését.
- A TDD arra is kényszerül, hogy csak a gyártói kódot írja be a tesztek teljesítéséhez a felhasználói igények alapján.
- Bizalom a refaktor iránt
- Ha refaktort kódol, akkor a kód megszakadásának lehetősége lehet. Tehát egy sor automatizált teszt segítségével kijavíthatja ezeket a töréseket a kiadás előtt. Megfelelő figyelmeztetést kapunk, ha az automatizált tesztek során szüneteket találunk.
- A TDD használatának gyorsabb, bővíthetőbb kódot kell eredményeznie, kevesebb hibával, amelyek minimális kockázattal frissíthetők.
- Jó csapatmunkára
Csapattag hiányában a csapat többi tagja könnyedén felveheti és kidolgozhatja a kódot. Támogatja a tudásmegosztást is, ezáltal hatékonyabbá téve a csapatot.
- Jó a fejlesztőknek
Bár a fejlesztőknek több időt kell eltölteniük a TDD tesztesetek megírásával, sokkal kevesebb időbe telik a hibakeresés és az új funkciók fejlesztése. Tisztább, kevésbé bonyolult kódot fog írni.
Összegzés:
- A TDD a tesztvezérelt fejlesztést jelenti. Ez egy olyan kód, amely módosítja a kódot annak érdekében, hogy sikeresen megfeleljen egy korábban tervezett tesztnek.
- Nagyobb hangsúlyt fektet a gyártási kódra, mint a teszteset tervezésére.
- A tesztvezérelt fejlesztés a kód módosításának folyamata, hogy megfeleljen egy korábban tervezett tesztnek.
- A szoftverfejlesztésben néha "Test First Development" néven ismert .
- A TDD magában foglalja a kód visszafejlesztését, vagyis bizonyos mennyiségű kód módosítását / hozzáadását a meglévő kódhoz anélkül, hogy befolyásolná a kód viselkedését.
- A TDD használatakor a kód világosabbá és érthetőbbé válik.
Ez a cikk Kanchan Kulkarni közreműködésével készült