Čo je testom riadený vývoj (TDD)? Výukový program s príkladom

Obsah:

Anonim

Testovaný vývoj

Test Driven Development (TDD) je prístup k vývoju softvéru, v ktorom sa vyvíjajú testovacie prípady s cieľom určiť a overiť, čo bude daný kód robiť. Zjednodušene povedané, najskôr sa vytvoria a otestujú testovacie prípady pre každú funkcionalitu. Ak test zlyhá, napíše sa nový kód, aby prešiel testom a bol kód jednoduchý a bez chýb.

Test-Driven Development začína navrhovaním a vývojom testov pre každú malú funkcionalitu aplikácie. TDD dáva vývojárom pokyn, aby nový kód napísali, iba ak zlyhal automatizovaný test. Tým sa zabráni duplikácii kódu. Plnou formou TDD je vývoj zameraný na testy.

Jednoduchý koncept TDD je zapísať a opraviť neúspešné testy pred napísaním nového kódu (pred vývojom). To pomáha vyhnúť sa duplikácii kódu, pretože pri písaní malého množstva kódu naraz absolvujeme testy. (Testy nie sú ničím iným ako požiadavkou, ktorú musíme splniť, aby sme ich splnili).

Testom riadený vývoj je proces vývoja a spustenia automatizovaného testu pred skutočným vývojom aplikácie. Preto sa TDD niekedy označuje aj ako Test First Development.

V tomto výučbe sa dozviete viac o-

  • Ako vykonať test TDD
  • TDD vs. Tradičné testovanie
  • Čo je TDD prijatia a TDD vývojára
  • Škálovanie TDD prostredníctvom agilného modelu riadeného vývoja (AMDD)
  • Test Driven Development (TDD) vs. Vývoj riadený agilným modelom (AMDD)
  • Príklad TDD
  • Výhody TDD

Ako vykonať test TDD

Nasledujúce kroky definujú, ako vykonať test TDD,

  1. Pridajte test.
  2. Spustite všetky testy a zistite, či nejaký nový test zlyhá.
  3. Napíš nejaký kód.
  4. Spustite testy a kód refaktora.
  5. Opakujte.

TDD cyklus definuje

  1. Napíš test
  2. Nech to beží.
  3. Zmeňte kód tak, aby bol správny, tj. Refaktor.
  4. Opakujte postup.

Niektoré objasnenia týkajúce sa TDD:

  • TDD nie je o „testovaní“, ani o „dizajne“.
  • TDD neznamená „napísať niektoré z testov a potom vytvoriť systém, ktorý testom vyhovie.
  • TDD neznamená „urobte veľa testov“.

TDD vs. Tradičné testovanie

Prístup TDD je primárne technikou špecifikácie. Zaisťuje, aby bol váš zdrojový kód dôkladne testovaný na potvrdzovacej úrovni.

  • Pri tradičnom testovaní úspešný test zistí jednu alebo viac chýb. Je to rovnaké ako s TDD. Ak test zlyhá, dosiahli ste pokrok, pretože viete, že je potrebné problém vyriešiť.
  • TDD zaisťuje, že váš systém skutočne spĺňa požiadavky definované preň. Pomáha budovať dôveru vo váš systém.
  • V TDD sa viac zameriava na produkčný kód, ktorý overuje, či bude testovanie fungovať správne. Pri tradičnom testovaní sa viac zameriava na dizajn testovacích prípadov. Či test ukáže správne / nesprávne vykonanie aplikácie s cieľom splniť požiadavky.
  • V TDD dosiahnete 100% test pokrytia. Na rozdiel od tradičného testovania je testovaný každý jeden riadok kódu.
  • Kombinácia tradičného testovania a TDD vedie skôr k dôležitosti testovania systému ako k dokonalosti systému.
  • V systéme Agile Modeling (AM) by ste mali „testovať s cieľom“. Mali by ste vedieť, prečo niečo testujete a na akej úrovni to musí byť testované.

Čo je TDD prijatia a TDD vývojára

Existujú dve úrovne TDD

  1. Prijatie TDD (ATDD): S ATDD napíšete jeden preberací test. Táto skúška spĺňa požiadavky špecifikácie alebo uspokojuje správanie systému. Potom napíšte len toľko produkčných / funkčných kódov, aby ste splnili uvedený akceptačný test. Akceptačný test sa zameriava na celkové správanie systému. ATDD bol tiež známy ako Behavioral Driven Development (BDD).
  2. Vývojár TDD: S vývojárom TDD napíšete jeden vývojársky test, tj. Test jednotky a potom už len toľko produkčného kódu, aby ste tento test splnili. Jednotkový test sa zameriava na každú malú funkčnosť systému. Vývojár TDD sa jednoducho nazýva TDD.

    Hlavným cieľom ATDD a TDD je špecifikovať podrobné a spustiteľné požiadavky na vaše riešenie na báze just in time (JIT). JIT znamená brať do úvahy iba tie požiadavky, ktoré sú v systéme potrebné. Takže zvyšujte účinnosť.

Škálovanie TDD prostredníctvom agilného modelu riadeného vývoja (AMDD)

TDD je veľmi dobrý v podrobnej špecifikácii a validácii. Nedokáže premýšľať o väčších problémoch, ako je celkový dizajn, používanie systému alebo používateľské rozhranie. AMDD rieši problémy s agilným škálovaním, ktoré TDD nerieši.

AMDD sa teda používa na väčšie problémy.

Životný cyklus AMDD.

V rámci MDD (Model-driven Development) sa pred napísaním zdrojového kódu vytvárajú rozsiahle modely. Ktoré majú zase agilný prístup?

Na hornom obrázku predstavuje každé políčko vývojovú aktivitu.

Envisioning je jedným z procesov TDD predpovedania / predstavovania testov, ktoré sa vykonajú počas prvého týždňa projektu. Hlavným cieľom predvídania je identifikovať rozsah systému a architektúru systému. Pre úspešné predvídanie sa robia vysoké požiadavky a modelovanie architektúry.

Je to proces, pri ktorom sa nerobí podrobná špecifikácia softvéru / systému, ale skúmanie požiadaviek softvéru / systému, ktorý definuje celkovú stratégiu projektu.

  1. Iterácia 0: Predvídanie

Existujú dva hlavné čiastkové aktivácie.

  1. Počiatočné predpokladané požiadavky.

    Zistenie vysokých požiadaviek a rozsahu systému môže trvať niekoľko dní. Hlavným zameraním je preskúmanie modelu použitia, modelu počiatočnej domény a modelu používateľského rozhrania (UI).

  2. Počiatočné architektonické predvídanie.

    Identifikácia architektúry systému tiež trvá niekoľko dní. Umožňuje stanovenie technických pokynov pre projekt. Hlavné zameranie je preskúmať technologické diagramy, tok používateľského rozhrania (UI), modely domén a prípady zmien.

  1. Iteračné modelovanie:

    Tu musí tím naplánovať prácu, ktorá bude vykonaná pre každú iteráciu.

  • Pre každú iteráciu sa používa agilný proces, tj. Počas každej iterácie bude s prioritou pridaná nová pracovná položka.
  • Budú sa brať do úvahy prvé práce s vyššou prioritou. Pridané pracovné položky môžu mať kedykoľvek prednosť v priorite alebo môžu byť zo stohu odstránené.
  • Tím diskutuje o tom, ako idú implementovať jednotlivé požiadavky. Na tento účel sa používa modelovanie.
  • Analýza a návrh modelovania sa vykonáva pre každú požiadavku, ktorá sa má pre túto iteráciu implementovať.
  1. Model zaútočil:

    Toto je tiež známe ako Just in time modeling.

  • Na tomto modelovaní sa zúčastňuje tím 2/3 členov, ktorí diskutujú o problémoch na papieri alebo tabuli.
  • Jeden člen tímu požiada druhého, aby s nimi modeloval. Táto relácia modelovania bude trvať približne 5 až 10 minút. Kde sa členovia tímu stretávajú, aby zdieľali tabuľu / papier.
  • Skúmajú problémy, kým nenájdu hlavnú príčinu problému. Ak jeden člen tímu včas zistí problém, ktorý chce vyriešiť, okamžite pomôže ostatným členom tímu.
  • Ostatní členovia skupiny potom preskúmajú problém a potom všetci pokračujú tak, ako predtým. Nazýva sa tiež ako stand-up modelovanie alebo relácie QA zákazníka.
  1. Testovaný vývoj (TDD).
  • Podporuje potvrdzujúce testovanie kódu vašej aplikácie a podrobnú špecifikáciu.
  • Vstupné údaje pre TDD sú jednak akceptačný test (podrobné požiadavky), jednak vývojové testy (unit test).
  • Vďaka TDD je kód jednoduchší a prehľadnejší. Umožňuje vývojárovi udržiavať menej dokumentácie.
  1. Recenzie.
  • Toto je voliteľné. Zahŕňa kontroly kódu a kontroly modelu.
  • To možno vykonať pre každú iteráciu alebo pre celý projekt.
  • Toto je dobrá voľba na poskytnutie spätnej väzby k projektu.

Test Driven Development (TDD) vs. Vývoj riadený agilným modelom (AMDD)

TDD AMDD
  • TDD skracuje spätnoväzbovú slučku programovania
  • AMDD skracuje slučku spätnej väzby modelovania.
  • TDD je podrobná špecifikácia
  • AMDD funguje pre väčšie problémy
  • TDD podporuje vývoj vysoko kvalitného kódu
  • AMDD podporuje vysokokvalitnú komunikáciu so zainteresovanými stranami a vývojármi.
  • TDD hovorí s programátormi
  • AMDD hovorí s obchodnými analytikmi, zainteresovanými stranami a dátovými profesionálmi.
  • TDD nie je vizuálne orientovaný
  • AMDD vizuálne orientované
  • TDD má obmedzený rozsah na softvérové ​​diela
  • AMDD má široký záber vrátane zainteresovaných strán. Zahŕňa to úsilie o dosiahnutie spoločného porozumenia
  • Oba podporujú evolučný vývoj
 --------------------------------------------

Príklad TDD

Tu v tomto príklade definujeme heslo triedy. Pre túto triedu sa pokúsime splniť nasledujúce podmienky.

Podmienka prijatia hesla:

  • Heslo by malo mať 5 až 10 znakov.

Najskôr napíšeme kód, ktorý spĺňa všetky vyššie uvedené požiadavky.

Scenár 1 : Na spustenie testu vytvoríme triedu PasswordValidator ();

Budeme bežať nad triedou TestPassword ();

Výstup je PRENOSENÝ, ako je uvedené nižšie;

Výstup :

Scenár 2 : Tu vidíme v metóde TestPasswordLength (), že nie je potrebné vytvárať inštanciu triedy PasswordValidator. Inštancia znamená vytvorenie objektu triedy na odkázanie členov (premenných / metód) tejto triedy.

Z kódu odstránime triedu PasswordValidator pv = new PasswordValidator (). Metódu isValid () môžeme zavolať priamo pomocou nástroja PasswordValidator. IsValid („Abc123“) . (Pozri obrázok nižšie)

Refaktorujeme teda (zmeníme kód), ako je uvedené nižšie:

Scenár 3 : Po refaktoringu výstup zobrazuje stav zlyhania (pozri obrázok nižšie), pretože sme odstránili inštanciu. Neexistuje teda žiadny odkaz na nestatickú metódu isValid ().

Takže musíme zmeniť túto metódu pridaním „statického“ slova pred Boolean ako verejného statického boolean isValid (heslo reťazca). Refactoring triedy PasswordValidator () na odstránenie vyššie uvedenej chyby, aby vyhovel testu.

Výkon:

Po vykonaní zmien v triede PassValidator (), ak spustíme test, bude výstup PRENESENÝ, ako je uvedené nižšie.

Výhody TDD

  • Včasné upozornenie na chybu.

    Vývojári testujú svoj kód, ale vo svete databáz to často pozostáva z manuálnych testov alebo jednorazových skriptov. Pomocou TDD si v priebehu času vytvoríte sadu automatizovaných testov, ktoré môžete vy a akýkoľvek iný vývojár znova spustiť podľa ľubovôle.

  • Lepšie navrhnutý, čistejší a rozšíriteľnejší kód.
    • Pomáha pochopiť, ako sa bude kód používať a ako interaguje s ostatnými modulmi.
    • Výsledkom je lepšie rozhodnutie o dizajne a udržiavateľnejší kód.
    • TDD umožňuje písanie menšieho kódu s jednou zodpovednosťou namiesto monolitických postupov s viacerými zodpovednosťami. Vďaka tomu je kód ľahšie pochopiteľný.
    • TDD tiež núti písať iba produkčný kód, aby prešiel testami na základe požiadaviek používateľov.
  • Dôvera refaktorovi
    • Ak refaktorujete kód, v kóde môžu byť možnosti zlomov. Takže máte sadu automatizovaných testov, ktoré môžete pred vydaním opraviť. Ak sa pri použití automatických testov zistia prerušenia, poskytne sa náležité varovanie.
    • Používanie TDD by malo mať za následok rýchlejší a rozšíriteľnejší kód s menším počtom chýb, ktoré je možné aktualizovať s minimálnymi rizikami.
  • Dobré pre tímovú prácu

    V prípade neprítomnosti člena tímu môžu ostatní členovia tímu kód ľahko zdvihnúť a pracovať na ňom. Pomáha tiež pri zdieľaní vedomostí, čím celkovo zvyšuje efektivitu tímu.

  • Dobré pre vývojárov

    Aj keď vývojári musia tráviť viac času písaním testovacích prípadov TDD, ladenie a vývoj nových funkcií trvá oveľa menej času. Budete písať čistejší a menej komplikovaný kód.

Zhrnutie:

  • TDD znamená Test-driven development. Jedná sa o proces úpravy kódu tak, aby prešiel testom navrhnutým predtým.
  • Viac sa kladie dôraz na produkčný kód ako na testovací prípad.
  • Vývoj zameraný na test je proces úpravy kódu tak, aby obstál v teste navrhnutom predtým.
  • V softvérovom inžinierstve sa to niekedy nazýva „Testujte prvý vývoj“.
  • TDD zahŕňa refaktoring kódu, tj zmenu / pridanie určitého množstva kódu k existujúcemu kódu bez ovplyvnenia správania kódu.
  • Ak sa použije TDD, kód sa stane jasnejším a zrozumiteľnejším.

K článku prispieva Kanchan Kulkarni