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

large__8282043567testovaný vývoj je proces, který se opírá o opakování velmi krátkého vývojového cyklu. Je založen na konceptu Extreme Programming (XP), který podporuje jednoduchý design s vysokou úrovní důvěry.

postup provádění TDD je následující:

  1. napište test
  2. spusťte všechny testy
  3. napište implementační kód
  4. spusťte všechny testy
  5. Refaktor

tento postup se často nazývá červeno-zelený Refaktor.

při psaní testů jsme v červeném stavu. Protože test je napsán před samotnou implementací, má selhat. Pokud tomu tak není, test je špatný. Popisuje něco, co již existuje nebo bylo napsáno nesprávně. Být při psaní testů zeleně je známkou falešně pozitivního. Takové testy by měly být odstraněny nebo změněny.

následuje zelený stát. Po dokončení implementace posledního testu by měly projít všechny testy. Pokud tak neučiní, implementace je špatná a měla by být opravena.

cílem není učinit implementaci konečnou, ale poskytnout dostatek kódu pro absolvování testů. Jakmile je vše zelené, můžeme pokračovat v refaktorování stávajícího kódu. To znamená, že děláme kód optimálnější bez zavedení nových funkcí. Zatímco refaktoring je na místě, všechny testy by měly projít po celou dobu. Pokud jeden z nich selže, refactor zlomil existující funkce. Refaktorování by nemělo zahrnovat nové testy.

rychlost je klíčem

large_5836417589
mám tendenci vidět TDD jako hru ping pong (nebo stolní tenis). Hra je velmi rychlá. Totéž platí pro TDD. Nemám tendenci trávit více než minutu na obou stranách stolu (test a implementace). Napište krátký test a spusťte jej (ping), napište implementaci a spusťte všechny testy (pong), napište další test (ping), napište implementaci tohoto testu( pong), refaktor a potvrďte, že všechny testy procházejí (skóre), opakujte. Ping, pong, ping, pong, ping, pong, skóre, sloužit znovu. Nesnažte se vytvořit dokonalý kód. Místo toho se snažte udržet míč v pohybu, dokud si nemyslíte, že je správný čas na skóre (refaktor).

nejde o testování

T v TDD je často nepochopeno. TDD je způsob, jakým přistupujeme k návrhu. Je to způsob, jak nás donutit přemýšlet o implementaci před napsáním kódu. Je to způsob, jak lépe strukturovat kód. To neznamená, že testy vyplývající z použití TDD jsou zbytečné. Daleko od toho. Jsou velmi užitečné a umožňují nám rozvíjet se velkou rychlostí, aniž bychom se obávali, že se něco zlomí. To platí zejména při refaktorování. Schopnost reorganizovat kód a zároveň mít jistotu, že není narušena žádná funkce, je obrovskou podporou kvality kódu.

hlavním cílem TDD je návrh kódu s testy jako velmi užitečným vedlejším produktem.

zesměšňování

aby testy probíhaly rychle a poskytovaly tak stálou zpětnou vazbu, musí být kód organizován tak, aby metody, funkce a třídy mohly být snadno zesměšňovány a strženy. Rychlost provedení bude vážně ovlivněna, například naše testy potřebují komunikovat s databází. Zesměšňováním vnějších závislostí jsme schopni tuto rychlost drasticky zvýšit. Provedení celé jednotky tests suite by mělo být měřeno v minutách, ne-li sekundách. Ještě důležitější než rychlost, navrhování kódu tak, aby mohl být snadno zesměšňován a stubbed nás nutí k lepší struktuře tohoto kódu použitím oddělení obav. S posměšky nebo bez nich by měl být kód napsán tak, abychom například mohli snadno nahradit jednu databázi jinou. Že „jiný“ může být například zesměšňován nebo in-memory databáze.

příklad zesměšňování ve Scale lze nalézt v Scala Test-Driven Development (TDD): Unit Testing file Operations with Specs2 and Mockito article. Pokud váš programovací jazyk volby není Scala, článek může být stále velmi užitečné, aby se vidět vzor, který lze použít na jakýkoli jazyk.

pozorovatelé

velmi užitečným nástrojem při práci v režimu TDD jsou pozorovatelé. Jsou to rámce nebo nástroje, které jsou spuštěny dříve, než začneme pracovat a sledujeme jakoukoli změnu kódu. Když je taková změna zjištěna, jsou spuštěny všechny testy. V případě JavaScriptu to umožňují téměř všechny systémy sestavení a běžci úloh. Gulp (můj oblíbený) a Grunt jsou dva z mnoha příkladů. Scala má revolver sbt (mimo jiné). Většina ostatních programovacích jazyků má podobné nástroje, které rekompilují (v případě potřeby) a spouštějí všechny (nebo ovlivněné) testy, když se kód změní. Vždycky skončím s rozdělením obrazovky na dvě okna. Jeden s kódem, na kterém pracuji, a druhý s výsledky testů, které jsou prováděny nepřetržitě. Jediné, co musím udělat, je věnovat pozornost tomu, že výstup těchto pozorovatelů odpovídá fázi, ve které se nacházím (červená nebo zelená).

dokumentace

dalším velmi užitečným vedlejším účinkem TDD (a dobře strukturovaných testů obecně) je dokumentace. Ve většině případů je mnohem snazší zjistit, co kód dělá při pohledu na testy, než samotná implementace. Další výhodou, kterou jiné typy dokumentace nemohou poskytnout, je to, že testy nejsou nikdy zastaralé. Pokud existuje nějaký rozpor mezi testy a implementačním kódem, testy selžou. Neúspěšné testy znamenají nepřesnou dokumentaci.

testy jako dokumentace článek poskytuje trochu hlubší zdůvodnění použití testů namísto tradiční dokumentace.

shrnutí

podle mých zkušeností je TDD pravděpodobně nejdůležitějším nástrojem, který máme v naší softwarové sadě nástrojů. Získání znalostí v TDD vyžaduje spoustu času a trpělivosti, ale jakmile je toto umění zvládnuto, produktivita a kvalita se drasticky zvyšují. Nejlepší způsob, jak se učit i cvičit TDD, je v kombinaci s párovým programováním. Stejně jako ve hře ping pong, která vyžaduje dva účastníky, TDD může být ve dvojicích, kde jeden kodér píše testy a druhý píše provádění těchto testů. Role se mohou přepínat po každém testu (jak se to často děje v kódování dojos).

zkuste to a nevzdávejte se, když čelíte překážkám, protože jich bude mnoho.

Test Driven Development (TDD): osvědčené postupy používající příklady Java jsou dobrým výchozím bodem. I když používá příklady Java, stejné, ne-li všechny, postupy lze použít na jakýkoli programovací jazyk. Pro příklad v Javě (stejně jako v předchozím případě, je snadno použitelné do jiných jazyků) , prosím, podívejte se na TDD příklad návod článek.

další skvělý způsob, jak k dokonalosti TDD dovednosti jsou kód katas (existuje mnoho na tomto webu).

jaké jsou vaše zkušenosti s TDD? Existuje tolik variant, kolik jsou týmy, které to praktikují, a rád bych slyšel o vašich zkušenostech.

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna.