Co je Test Driven Development (TDD)? Výukový program s příkladem

Obsah:

Anonim

Testovaný vývoj

Test Driven Development (TDD) je přístup k vývoji softwaru, ve kterém jsou vyvíjeny testovací případy, které specifikují a ověřují, co bude kód dělat. Zjednodušeně řečeno, testovací případy pro každou funkcionalitu jsou vytvořeny a testovány jako první, a pokud test selže, je napsán nový kód, aby vyhověl testu a aby byl kód jednoduchý a bez chyb.

Test-Driven Development začíná návrhem a vývojem testů pro každou malou funkčnost aplikace. TDD dává vývojářům pokyn, aby napsali nový kód, pouze pokud selhal automatický test. Tím se zabrání duplikaci kódu. Plnou formou TDD je vývoj zaměřený na testování.

Jednoduchý koncept TDD je psát a opravovat neúspěšné testy před zápisem nového kódu (před vývojem). To pomáhá vyhnout se duplikaci kódu, protože píšeme malé množství kódu najednou, abychom mohli projít testy. (Testy nejsou nic jiného než podmínky požadavku, které musíme otestovat, abychom je splnili).

Test-Driven development je proces vývoje a spuštění automatizovaného testu před skutečným vývojem aplikace. Proto TDD někdy také nazýván jako Test First Development.

V tomto tutoriálu se dozvíte více o-

  • Jak provést test TDD
  • TDD vs. Tradiční testování
  • Co je TDD přijetí a TDD vývojáře
  • Škálování TDD prostřednictvím Agile Model Driven Development (AMDD)
  • Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)
  • Příklad TDD
  • Výhody TDD

Jak provést test TDD

Následující kroky definují, jak provést test TDD,

  1. Přidejte test.
  2. Spusťte všechny testy a zkontrolujte, zda některý nový test selže.
  3. Napište nějaký kód.
  4. Spusťte testy a kód Refactor.
  5. Opakovat.

Definuje TDD cyklus

  1. Napište test
  2. Nech to běžet.
  3. Změňte kód, aby byl správný, tj. Refactor.
  4. Opakujte postup.

Některá vysvětlení týkající se TDD:

  • TDD není ani o „testování“, ani o „designu“.
  • TDD neznamená „napsat některé z testů a poté vytvořit systém, který testy projde.
  • TDD neznamená „dělat hodně testování“.

TDD vs. Tradiční testování

Přístup TDD je primárně specifikační technikou. Zajišťuje důkladné testování zdrojového kódu na potvrzovací úrovni.

  • Při tradičním testování najde úspěšný test jednu nebo více vad. Je to stejné jako TDD. Když test selže, udělali jste pokrok, protože víte, že je třeba problém vyřešit.
  • TDD zajišťuje, že váš systém skutečně splňuje požadavky definované pro něj. Pomáhá budovat důvěru ve váš systém.
  • V TDD se více zaměřuje na produkční kód, který ověřuje, zda testování bude fungovat správně. V tradičním testování se více zaměřuje na design testovacích případů. Zda test ukáže správné / nesprávné provedení aplikace za účelem splnění požadavků.
  • V TDD dosáhnete 100% testu pokrytí. Každý jednotlivý řádek kódu je testován, na rozdíl od tradičního testování.
  • Kombinace tradičního testování a TDD vede spíše k důležitosti testování systému než k dokonalosti systému.
  • V Agile Modeling (AM) byste měli „testovat s určitým účelem“. Měli byste vědět, proč něco testujete a na jaké úrovni to musí být testováno.

Co je TDD přijetí a TDD vývojáře

Existují dvě úrovně TDD

  1. Přijetí TDD (ATDD): S ATDD napíšete jeden přejímací test. Tato zkouška splňuje požadavek specifikace nebo vyhovuje chování systému. Poté napište jen tolik produkčních / funkčních kódů, abyste splnili tento akceptační test. Akceptační test se zaměřuje na celkové chování systému. ATDD byl také známý jako Behavioral Driven Development (BDD).
  2. Developer TDD: S Developer TDD píšete jeden vývojářský test, tj. Test jednotky a pak jen tolik produkčního kódu, abyste tento test splnili. Test jednotky se zaměřuje na každou malou funkčnost systému. Vývojář TDD se jednoduše nazývá TDD.

    Hlavním cílem ATDD a TDD je specifikovat podrobné, spustitelné požadavky na vaše řešení na bázi just in time (JIT). JIT znamená vzít v úvahu pouze ty požadavky, které jsou v systému potřebné. Takže zvyšte účinnost.

Škálování TDD prostřednictvím Agile Model Driven Development (AMDD)

TDD je velmi dobrý v podrobné specifikaci a validaci. Nedokáže promyslet větší problémy, jako je celkový design, použití systému nebo uživatelské rozhraní. AMDD řeší problémy s agilním měřítkem, které TDD ne.

AMDD se tedy používá pro větší problémy.

Životní cyklus AMDD.

V Model-driven Development (MDD) se před zápisem zdrojového kódu vytvářejí rozsáhlé modely. Které zase mají agilní přístup?

Na obrázku výše představuje každé pole vývojovou aktivitu.

Envisioning je jedním z TDD procesů předpovídání / představování testů, které budou provedeny během prvního týdne projektu. Hlavním cílem předvídání je identifikovat rozsah systému a architekturu systému. Požadavky na vysoké úrovni a modelování architektury se provádí pro úspěšné předvídání.

Je to proces, kde se neprovádí podrobná specifikace softwaru / systému, ale zkoumání požadavků softwaru / systému, který definuje celkovou strategii projektu.

  1. Iterace 0: Předvídání

Existují dvě hlavní dílčí aktivace.

  1. Počáteční požadavky předpokládat.

    Zjištění vysokých požadavků a rozsahu systému může trvat několik dní. Hlavním zaměřením je prozkoumat model využití, model počáteční domény a model uživatelského rozhraní (UI).

  2. Počáteční architektonické představy.

    Identifikace architektury systému také trvá několik dní. Umožňuje stanovit technické směry projektu. Hlavním zaměřením je prozkoumat technologické diagramy, tok uživatelského rozhraní (UI), modely domény a případy změn.

  1. Iterační modelování:

    Zde musí tým naplánovat práci, která bude provedena pro každou iteraci.

  • Agilní proces se používá pro každou iteraci, tj. Během každé iterace bude přidána nová pracovní položka s prioritou.
  • Budou brány v úvahu první práce s vyšší prioritou. Přidané pracovní položky mohou být kdykoli změněny podle priority nebo odstraněny ze zásobníku položek.
  • Tým diskutuje o tom, jak budou každý požadavek implementovat. K tomuto účelu se používá modelování.
  • Analýza a návrh modelování se provádí pro každý požadavek, který bude pro tuto iteraci implementován.
  1. Model zaútočil:

    Toto je také známé jako Just in time Modeling.

  • Tady modelování zahrnuje tým 2/3 členů, kteří diskutují o problémech na papíře nebo tabuli.
  • Jeden člen týmu požádá jiného, ​​aby s nimi modeloval. Tato relace modelování bude trvat přibližně 5 až 10 minut. Kde se členové týmu shromažďují, aby sdíleli tabuli / papír.
  • Zkoumají problémy, dokud nenajdou hlavní příčinu problému. V pravý čas, pokud jeden člen týmu identifikuje problém, který chce vyřešit, přijme rychlou pomoc ostatních členů týmu.
  • Ostatní členové skupiny poté prozkoumají problém a poté všichni pokračují jako dříve. Nazývá se také jako stand-up modelování nebo relace QA zákazníka.
  1. Test Driven Development (TDD).
  • Podporuje potvrzující testování kódu vaší aplikace a podrobnou specifikaci.
  • Přijímací zkouška (podrobné požadavky) a vývojářské testy (test jednotky) jsou vstupy pro TDD.
  • Díky TDD je kód jednodušší a přehlednější. Umožňuje vývojáři udržovat méně dokumentace.
  1. Recenze.
  • Toto je volitelné. Zahrnuje kontroly kódu a kontroly modelu.
  • To lze provést pro každou iteraci nebo pro celý projekt.
  • To je dobrá volba pro poskytnutí zpětné vazby k projektu.

Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)

TDD AMDD
  • TDD zkracuje smyčku zpětné vazby programování
  • AMDD zkracuje smyčku zpětné vazby modelování.
  • TDD je podrobná specifikace
  • AMDD funguje pro větší problémy
  • TDD podporuje vývoj vysoce kvalitního kódu
  • AMDD podporuje vysoce kvalitní komunikaci se zúčastněnými stranami a vývojáři.
  • TDD mluví s programátory
  • AMDD hovoří s obchodními analytiky, zúčastněnými stranami a datovými profesionály.
  • TDD není vizuálně orientovaný
  • AMDD vizuálně orientovaný
  • TDD má omezený rozsah na softwarová díla
  • AMDD má široký záběr včetně zúčastněných stran. Zahrnuje to úsilí o dosažení společného porozumění
  • Oba podporují vývojový vývoj
 --------------------------------------------

Příklad TDD

Zde v tomto příkladu definujeme heslo třídy. U této třídy se pokusíme splnit následující podmínky.

Podmínka pro přijetí hesla:

  • Heslo by mělo mít 5 až 10 znaků.

Nejprve napíšeme kód, který splňuje všechny výše uvedené požadavky.

Scénář 1 : Pro spuštění testu vytvoříme třídu PasswordValidator ();

Budeme běžet nad třídou TestPassword ();

Výstup je PASSED, jak je znázorněno níže;

Výstup :

Scénář 2 : Zde vidíme v metodě TestPasswordLength (), že není třeba vytvářet instanci třídy PasswordValidator. Instance znamená vytvoření objektu třídy, který bude odkazovat na členy (proměnné / metody) dané třídy.

Z kódu odstraníme třídu PasswordValidator pv = new PasswordValidator (). Metodu isValid () můžeme volat přímo pomocí PasswordValidator. IsValid („Abc123“) . (Viz obrázek níže)

Takže jsme Refaktor (změna kódu), jak je uvedeno níže:

Scénář 3 : Po refaktoringu výstup ukazuje stav selhání (viz obrázek níže), je to proto, že jsme instanci odstranili. Neexistuje tedy žádný odkaz na nestatickou metodu isValid ().

Musíme tedy tuto metodu změnit přidáním „statického“ slova před Boolean jako veřejného statického boolean isValid (heslo řetězce). Refactoring třídy PasswordValidator () k odstranění výše uvedené chyby pro úspěšné absolvování testu.

Výstup:

Po provedení změn ve třídě PassValidator (), pokud spustíme test, bude výstup PASSED, jak je znázorněno níže.

Výhody TDD

  • Včasné upozornění na chybu.

    Vývojáři testují svůj kód, ale ve světě databází se to často skládá z manuálních testů nebo jednorázových skriptů. Pomocí TDD si v průběhu času vytvoříte sadu automatických testů, které můžete vy a jakýkoli jiný vývojář libovolně znovu spustit.

  • Lepší design, čistší a rozšiřitelnější kód.
    • Pomáhá pochopit, jak bude kód použit a jak interaguje s jinými moduly.
    • Výsledkem je lepší rozhodnutí o návrhu a udržovatelnější kód.
    • TDD umožňuje psát menší kód, který má jednu odpovědnost, spíše než monolitické postupy s více odpovědnostmi. Díky tomu je kód srozumitelnější.
    • TDD také nutí psát pouze produkční kód, aby předal testy na základě požadavků uživatele.
  • Důvěra k refaktorovi
    • Pokud refaktorujete kód, mohou v kódu existovat možnosti přerušení. Takže máte sadu automatických testů, které můžete opravit před uvolněním. Pokud se při použití automatických testů zjistí přerušení, bude vydáno správné varování.
    • Použití TDD by mělo vést k rychlejšímu a rozšiřitelnějšímu kódu s menším počtem chyb, které lze aktualizovat s minimálním rizikem.
  • Dobré pro týmovou práci

    V nepřítomnosti jakéhokoli člena týmu mohou ostatní členové týmu kód snadno vyzvednout a pracovat na něm. Pomáhá také sdílení znalostí, čímž celkově zefektivňuje tým.

  • Dobré pro vývojáře

    Ačkoli vývojáři musí trávit více času psaním testovacích případů TDD, trvá mnohem méně času na ladění a vývoj nových funkcí. Budete psát čistší a méně komplikovaný kód.

Souhrn:

  • TDD znamená Test-driven development. Jedná se o proces úpravy kódu, aby vyhověl dříve navrženému testu.
  • Je to větší důraz na produkční kód než na design testovacího případu.
  • Vývoj zaměřený na testování je proces úpravy kódu, aby vyhověl dříve navrženému testu.
  • V softwarovém inženýrství se někdy označuje jako „Test First Development“.
  • TDD zahrnuje refaktorování kódu, tj. Změnu / přidání určitého množství kódu do stávajícího kódu, aniž by to ovlivnilo chování kódu.
  • Při použití TDD je kód jasnější a srozumitelnější.

K tomuto článku přispěl Kanchan Kulkarni