Co je Test Driven Development (TDD)? Výukový program s ukázkou

Vývoj zaměřený na testování 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 napsat a opravit neúspěšné testy před zápisem nový kód (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.)

Vývoj zaměřený na testování je proces vývoje a provozu automatizovaného test před skutečným vývojem aplikace. Proto TDD někdy také nazýván jako Test First Development.

V tomto výukovém programu se dozvíte více o –

• Jak provádět test TDD
• TDD vs. Tradiční testování
• Co je to přijetí TDD a Developer TDD
• Škálování TDD pomocí Agile Model Driven Development (AMDD)
• Test Driven Development (TDD) vs. Agile Model Driven Development (AMDD)
• Příklad TDD
• Výhody TDD

Jak provést TDD Test

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

1. Přidat test.
2. Spustit všechny testy a zjistit, zda některý nový test selže.
3. Napište nějaké kód.
4. Spusťte testy a kód refaktorů.
5. Opakujte.

Definuje cyklus TDD

1. Napsat test
2. Spustit.
3. Změnit kód aby to bylo 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ů, pak vytvořit systém, který testy projde.
• TDD neznamená„ dělat hodně testů. „

TDD vs. tradiční testování

Přístup TDD je primárně technikou specifikace. Zajišťuje důkladné testování vašeho zdrojového kódu při potvrzování úroveň.

• U tradičního testování nalezne ú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á vám 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ý řá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 Agilní modelování (AM), měli byste „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 přijetí TDD a Developer TDD

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 test vývojáře, tj. test jednotky a pak jen tolik produkčního kódu, který tento test splní. 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é a spustitelné požadavky pro 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 pomocí 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.

Ve vývoji založeném na modelech (MDD) se před vytvořením zdrojový kód je zapsán. Které zase mají agilní přístup?

Na výše uvedeném obrázku každé pole představuje 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í dva hlavní dílčí aktivace.

1. Počáteční požadavky.

   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.
• První vyšší priorita bude brána v úvahu práce. 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ý se má pro tuto iteraci implementovat.

1. Útok na model:

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

• Tady se modelování účastní tým 2/3 členů, kteří diskutují o problémech na papíře nebo tabuli.
• Jeden člen týmu požádá jiného modelovat s nimi. 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 k vyřešení pak rychle využije pomoc ostatních členů týmu.
• Ostatní členové skupiny poté prozkoumají problém a pak všichni pokračují jako dříve. Nazývá se také jako modelování stand-upů nebo QA relace zákazníka .

1. Test Driven Development (TDD).

• Podporuje potvrzující testování kódu vaší aplikace a podrobnou specifikaci.
• Přijímací test (podrobné požadavky) i vývojářské testy (test jednotky) jsou vstupy pro TDD.
• TDD zjednodušuje a srozumitelně kóduje. Umožňuje vývojáři spravovat méně dokumentace.

1. Recenze.

• Toto je volitelné. Zahrnuje kontroly kódu a kontroly modelu.
• Může to být provedeno pro každou iteraci nebo pro celý projekt.
• Toto je dobrá volba pro poskytnutí zpětné vazby k projektu.

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

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

Spustíme nad třídou TestPassword ();

Výstup je PŘENOSEN, jak je uvedeno níže;

Výstup:

Scénář 2: Zde můžeme viz metoda TestPasswordLength () 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 ().

Takže musíme změnit tuto metodu přidáním „statického“ slova před Boolean jako veřejné statické 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 provedeme test, bude výstup PASSED, jak je uvedeno níže.

Výhody TDD

• Předčasná chyba oznámení.

  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ší navržený, č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 s jedinou odpovědností spíše než monolitické postupy s více odpovědnostmi. Díky tomu je kód snazší pochopit.
  • 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í, zobrazí se 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 žádného č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, ladění a vývoj nových funkcí zabere mnohem méně času. Budete psát čistší a méně komplikovaný kód.

Shrnutí:

• TDD znamená Test-driven development. Jedná se o proces úpravy kódu, aby vyhověl dříve navrženému testu.
• Důraz je kladen spíše na produkční kód než na návrh testovacích případů.
• Vývoj zaměřený na testování je proces úpravy kódu tak, aby vyhověl dříve navrženému testu.
• V softwarovém inženýrství je někdy známý 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.
• TDD při použití bude kód jasnější a jednodušší rozumět.

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