Co je to testem řízený vývoj (TDD)? Příklad

Od: Thomas Hamilton Thomas Hamilton
Hours aktualizováno

Co je to testem řízený vývoj (TDD)?

Testem řízený vývoj (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. Jednoduše řečeno, testovací případy pro každou funkci jsou nejprve vytvořeny a otestovány, a pokud test selže, je napsán nový kód, aby prošel testem a aby byl kód jednoduchý a bez chyb.

Testem řízený vývoj začíná návrhem a vývojem testů pro každou malou funkcionalitu aplikace. TDD framework instruuje vývojáře, aby napsali nový kód pouze v případě, že automatický test selhal. Tím se zabrání duplicitě kódu. Plná forma TDD je vývoj řízený testem.

Test řízený vývoj

Jednoduchý koncept TDD je napsat a opravit neúspěšné testy před napsáním nového kódu (před vývojem). To pomáhá vyhnout se duplicitě kódu, když píšeme malé množství kódu najednou, abychom prošli testy. (Testy nejsou nic jiného než podmínky požadavků, které musíme testovat, abychom je splnili).

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

Jak provést TDD test

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

  1. Přidejte test.
  2. Spusťte všechny testy a zjistěte, zda některý nový test selže.
  3. Napište nějaký kód.
  4. Spusťte testy a Refaktorujte kód.
  5. Opakovat.
Proveďte test TDD
Pět kroků vývoje řízeného testováním

TDD cyklus definuje

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

Některá vysvětlení ohledně TDD:

  • Přístup TDD není ani o „testování“, ani o „designu“.
  • TDD neznamená „napište nějaké testy, pak vytvořte systém, který testy projde.
  • TDD neznamená „dělat hodně testování“.

TDD vs. Tradiční testování

Níže je uveden hlavní rozdíl mezi vývojem řízeným testováním a tradičním testováním:

TDD přístup je primárně specifikační technika. Zajistí, že váš zdrojový kód bude důkladně otestován na potvrzující úrovni.

  • Při tradičním testování úspěšný test najde jeden nebo více defektů. Je to stejné jako TDD. Když test selže, udělali jste pokrok, protože víte, že musíte problém vyřešit.
  • TDD zajišťuje, že váš systém skutečně splňuje požadavky pro něj definované. Pomáhá budovat vaši 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 návrh testovacího případu. Zda test ukáže správné/nesprávné provedení aplikace za účelem splnění požadavků.
  • V TDD dosáhnete 100% testu pokrytí. Na rozdíl od tradičního testování je testován každý jeden řádek kódu.
  • Kombinace tradičního testování a TDD vede k důležitosti testování systému spíše než k dokonalosti systému.
  • In 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 je to potřeba testovat.

SOUVISEJÍCÍ ČLÁNKY

Co je akceptace TDD a Developer TDD

Existují dvě úrovně TDD

  1. Přijímací TDD (ATDD): S ATDD napíšete jeden přijímací test. Tento test splňuje požadavek specifikace nebo vyhovuje chování systému. Poté napište jen tolik produkčního/funkčního kódu, abyste splnili tento akceptační test. Akceptační test se zaměřuje na celkové chování systému. ATDD byl také známý jako Vývoj řízený chováním (BDD).
  2. Vývojář TDD: S Developer TDD napíšete jediný vývojářský test, tj. unit test a pak jen tolik produkčního kódu, abyste tento test splnili. Unit test se zaměřuje na každou drobnou funkcionalitu systému. Developer TDD se jednoduše nazývá jako TDD.Hlavním cílem ATDD a TDD je specifikovat podrobné, proveditelné požadavky na vaše řešení na základě just in time (JIT). JIT znamená brát v úvahu pouze ty požadavky, které jsou v systému potřeba. Zvyšte tedy efektivitu.

Akceptační TDD a Developer TDD

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

TDD je velmi dobrý v podrobné specifikaci a ověřování. Selhává při promýšlení větších problémů, jako je celkový design, použití systému nebo uživatelské rozhraní. AMDD řeší problémy agilního škálování, které TDD neřeší.

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

Životní cyklus AMDD

Životní cyklus AMDD

V modelem řízeném vývoji (MDD) jsou rozsáhlé modely vytvářeny před napsáním zdrojového kódu. Které mají zase agilní přístup?

Na obrázku výše každý rámeček představuje vývojovou aktivitu.

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

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

Iterace 0: Představa

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

  1. Předvídání počátečních požadavků.Identifikace požadavků na vysoké úrovni a rozsahu systému může trvat několik dní. Hlavním cílem je prozkoumat model použití, model počáteční domény a model uživatelského rozhraní (UI).
  2. Počáteční Architechnické představy. Identifikace architektury systému také trvá několik dní. Umožňuje nastavit technické směry projektu. Hlavním cílem je prozkoumat technologické diagramy, tok uživatelského rozhraní (UI), modely domén a případy změn.

Iterační modelování

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

  • Pro každou iteraci se používá agilní proces, tj. během každé iterace bude prioritně přidána nová pracovní položka.
  • První práce s vyšší prioritou budou brány v úvahu. Přidané pracovní položky mohou být kdykoli změněny nebo odstraněny ze zásobníku položek.
  • Tým diskutuje o tom, jak budou jednotlivé požadavky 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 danou iteraci implementován.

Modelová bouře

Toto je také známé jako modelování Just in time.

  • Zde modelování zahrnuje tým 2/3 členů, kteří diskutují o problémech na papíře nebo na tabuli.
  • Jeden člen týmu požádá druhého, aby s ním modeloval. Toto modelování zabere přibližně 5 až 10 minut. Kde se členové týmu scházejí, aby sdíleli tabuli/papír.
  • Zkoumají problémy, dokud nenajdou hlavní příčinu problému. Právě vč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 pak problém prozkoumají a pak všichni pokračují jako předtím. Nazývá se také jako stand-up modelování nebo sezení kontroly kvality zákazníků.

Testem řízený vývoj (TDD)

  • Podporuje potvrzující testování kódu vaší aplikace a podrobné specifikace.
  • Vstupy pro TDD jsou jak akceptační test (podrobné požadavky), tak vývojářské testy (test jednotky).
  • TDD dělá kód jednodušší a přehlednější. Umožňuje vývojáři udržovat méně dokumentace.

Hodnocení

  • Toto je nepovinné. Zahrnuje kontroly kódu a recenze modelů.
  • To lze provést pro každou iteraci nebo pro celý projekt.
  • Je to dobrá možnost, jak poskytnout zpětnou vazbu k projektu.

Testem řízený vývoj (TDD) vs. Agilní modelem řízený vývoj (AMDD)

TDD AMDD
TDD zkracuje zpětnovazební smyčku programování AMDD zkracuje zpětnovazební smyčku modelování.
TDD je podrobná specifikace AMDD funguje na 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 mluví Business Analyst, zúčastněné strany a datoví profesionálové.
TDD nevizuálně orientované AMDD vizuálně orientované
TDD má omezený rozsah na softwarové práce AMDD má široký záběr včetně zainteresovaných stran. Zahrnuje práci na společném porozumění
Oba podporují evoluční vývoj ---------------

TDD rámce

Zde je seznam nejlepších testovacích vývojových rámců (TDD).

  1. Junit
  2. TestNG
  3. csUnit a NUnit
  4. Rspec

Nyní se pojďme naučit Test Driven Development na příkladu.

Příklad TDD

Zde v tomto příkladu Test Driven Development definujeme heslo třídy. Pro tuto třídu 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 v tomto příkladu TDD napíšeme kód, který splňuje všechny výše uvedené požadavky.

Příklad TDD

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

Příklad TDD

Poběžíme nad třídou TestPassword ();

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

Výstup:

Příklad TDD

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

Příklad TDD

Z kódu odstraníme třídu PasswordValidator pv = new PasswordValidator (). Můžeme zavolat na je platná () metodou přímo PasswordValidator. IsValid („Abc123“). (Viz obrázek níže)

Refaktorujeme (změníme kód), jak je uvedeno níže:

Příklad TDD

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

Příklad TDD

Tuto metodu tedy musíme změnit přidáním „statického“ slova před booleovské slovo jako veřejné statické booleovské isValid (string heslo). Refaktoring Class PasswordValidator () k odstranění výše uvedené chyby, aby prošel testem.

Příklad TDD

Výstup:

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

Příklad TDD

Výhody TDD

Níže jsou uvedeny hlavní výhody vývoje řízeného testováním v softwarovém inženýrství:

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 ručních testů nebo jednorázových skriptů. Pomocí TDD si postupem času vytvoříte sadu automatických testů, které můžete vy a kterýkoli jiný vývojář libovolně opakovat.

Lepší design, čistší a rozšiřitelnější kód.

  • Pomáhá pochopit, jak bude kód používán a jak interaguje s ostatními moduly.
  • Výsledkem je lepší rozhodnutí o návrhu a lépe udržovatelný kód.
  • TDD umožňuje psát menší kód s jedinou odpovědností spíše než monolitické procedury s více odpovědnostmi. Díky tomu je kód jednodušší na pochopení.
  • TDD také nutí psát pouze produkční kód, aby prošel testy na základě požadavků uživatelů.

Důvěra Refactoru

  • Pokud kód refaktorujete, může se stát, že v kódu dojde k přerušení. Díky sadě automatických testů můžete tyto přestávky před vydáním opravit. Pokud jsou při použití automatických testů nalezeny přestávky, zobrazí se řádné 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ími riziky.

Dobré pro týmovou práci

  • V nepřítomnosti kteréhokoli člena týmu mohou ostatní členové týmu kód snadno vyzvednout a pracovat na něm. Napomáhá také sdílení znalostí, čímž je tým celkově efektivnější.

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ší, méně komplikovaný kód.

Shrnutí

  • TDD znamená vývoj řízený testem.
  • Význam TDD: Jedná se o proces úpravy kódu, aby prošel dříve navrženým testem.
  • Klade větší důraz na produkční kód než na návrh testovacího případu.
  • Testem řízený vývoj je proces úpravy kódu, aby prošel dříve navrženým testem.
  • In Softwarové inženýrství, To je někdy známé jako "Test první vývoj."
  • Testování 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 bez ovlivnění chování kódu.
  • Při použití programování TDD se kód stává jasnějším a srozumitelnějším.