Vývoj řízený testy, Předmluva

TDD: Předmluva

Cílem vývoje řízeného testy (Test-Driven Development - TDD) je, jak to brilantně vyjádřil Ron Jeffries, "Čistý kód který funguje". Takový kód se vyplatí vytvářet hned z několika důvodů:

Jde o předvídatelný způsob vývoje . Víte, kdy jste hotovi, aniž byste se museli zabývat seznamem chyb.

Máte příležitost poučit se ze všech lekcí, které vám kód může dát. Použijete-li pouze první nápad, na který přijdete, nikdy nebudete mít příležitost přemýšlet o dalším, lepším nápadu.
Zlepšíte život uživatelů vašich programů.
Můžete se spolehnout na své spolupracovníky a oni zase na vás.
Je příjemné psát tímto způsobem.

Jak však takový kód získáme? Od vytvoření čistého a fungujícího kódu nás odvádí mnoho činitelů. Žádný strach. Můžeme začít rozhodovat o dalším postupu na základě výsledků automatizovaných testů. Tento styl vývoje se nazývá vývoj řízený testy (TDD).

V testy řízeném vývoji vždy:

píšeme nový kód pouze tehdy, když automatizovaný test selže a
když eliminujeme duplicitu

Jsou to jednoduchá pravidla, ale vytvářejí komplexní chování skupin a jednotlivců, které má následující technické důsledky:

Musíme tvořit organicky a využívat fungující kód k získání zpětné vazby o našich předchozích rozhodnutích.
Musíme psát vlastní testy, protože nemůžeme čekat dvacetkrát denně, než někdo jiný test napíše.
Naše vývojové prostředí musí poskytovat rychlou odezvu na malé změny.
Naše návrhy se musí skládat z mnoha vysoce soudržných (Soudržnost (cohesion) třídy či komponenty je nepřímo úměrná počtu a rozptylu úkolů, za které je třída (komponenta) zodpovědná. V deálním případě by třída měla být zodpovědná za jediný úkol a každá její metoda by měla řešit jednu jednoduchou úlohu), volně propojených (Propojenost (coupling) tříd či komponent označuje míru vzájemné závislosti kódu jednotlivých tříd a tím i míru nutných změn kódu jiných tříd (komponent) zapříčiněných změnou kódu jedné třídy (komponenty). Volným propojením (loosely coupling) označujeme stav, kdy změna kódu jedné třídy (komponenty) nevyvolá nutnost změny kódu ostatních tříd (komponent)) komponent usnadňujících testování.

Níže uvedená pravidla určují pořadí úkolů při programování.

Červená: Napište malý test, který nefunguje, a možná napoprvé nejde ani zkompilovat.
Zelená: Rychle zprovozněte test a neváhejte se přitom prohřešit proti čemukoli
Refaktorování: Zbavte se všech duplicit vytvořených ve snaze zprovoznit test.

Červená / Zelená / Refaktorování je Otčenášem vývoje řízeného testy.

Pokud by takový programovací styl byl možný, mohli bychom výrazně snížit výskyt chyb v kódu a neméně výrazně zpřehlednit program pro všechyn zůčastněné. Psaní pouze takového kódu, který je vynucen neúspěšnými testy by mělo i další dopady.

Je-li možné dostateční snížit výskyt chyb, můža zajištění kvality spočívat v aktivnější práci a ne pouze v reakcích na chybu.
Je-li možné dostatečně snížit počet nepříjemných překvapení, může manažer projektu dosáhnout přesnějšího odhadu a při vývoji lépe rozdělit úlohy.
Je-li možné dostatečně vyjasnit témata technické konverzace, mohou programátoři namísto denních nebo měsíčních setkání spolupracovat průběžně.
A znovu, je-li možné dostatečně snížit množství chyb, lze dodávat programy s novými funkcemi prakticky každý den, a tím získávat nové obchodní vztahy se zákazníky.

Koncepce je tady jednoduchá, ale proč to všechno? Proč by si měli programátoři přidělávat práci s psaním automatizovaných testů? Proč by měl programátor pracovat krůček po krůčku, když se jeho či její smysl vznáší v oblacích návrhu? Kvůli odvaze.

Odvaha

Vývoj řízený testy je způsob, jak zvládnout strach během programování. Nemám na mysli strach ve špatném slova smyslu - strachy bulí, bulí Bulíček, koupíme mu dudlíček - ale přípustný strach ve smyslu "je to vážný problém a nevím, jak na něj". Říká-li nám příroda bolestí "Dost!", potom strachem říká "Pozor!". Mít se na pozoru je dobré, ale strach má spoustu vedlejších účinků:

strach z vás dělá váhavce
strach snižuje vaši potřebu komunikovat
strach přináší obavy ze zpětné vazby
strach z vás dělá bručouny

Žádný z těchto účinků vám při programování nepomůže. Zvláště pokud programujete něco těžkého. Otázka tedy zní: "Jak čelit obtížným situacím a

místo váhání se co nejrychlejí poučit z konkrétních situací,
místo uzavírání se do sebe jasněji komunikovat,
místo vyhýbání se zpětné vazbě vyhledávat prospěšnou, konkrétní odezvu?"
(S bručounstvím si budete muset poradit sami)

Představte si progamování jako točení klikou při vytahování vědra vody ze studny. Je-li vědro malé, stačí nám volně se otáčející klika. Je-li vědro velké a plné vody, unavíte se dříve než se vědro dostane nahoru. Potřebujete západkový mechanizmus, abyste si mohli během točení odpočinout. čím je vědro težší, tím blíže musí být zuby na západce.

Při vývji řízeném testy jsou testy zuby západky. Jakmile se nám podaří jeden test zprovoznit, víme, že funguje jednou provždy. Jsme opět krůček blíže k tomu, aby všechno fungovalo, než jsme byli, když minulý test selhal. Nyní se pustíme do zprovoznění dalšího a dalšího a dalšího testu. Analogicky: čím horší je problém při progamování, tím menší je oblast, kterou by měl test pokrývat.

Čtenáři mé knihy "Extrémní programování" si všimnou rozdílů v povaze extrémního programování (XP) a TDD. TDD není tak dogmatické jako XP. XP říká: "Zde jsou věci, které musíte být schopni udělat, abyste se mohli pohnout dále." TDDje o něco liberálnější. TDD znamená uvědomit si během programování prostor mezi rozhodnutím a zpětnou vazbou a poskytuje techniky, pomocí nichž lze tento prostor ovládat. "Co když celý týden vytvářím návrh na papíře, a pak kód řídím pomocí testů? Jedná se o TDD?"

Jistěže se jedná o TDD. Byli jste si vědomi prostoru mezi rozhodnutím a zpětnou vazbou a záměrně jste s tímto prostorem pracovali.

Za těchto předpokladů většina lidí kteří se učí TDD zjistí, že se jejich programovací techniky zlepšily. Erich Gamma zavedl pro popis tohoto posunu termín "Nakažen testováním". Možná že zjistíte, že píšete více časných testů a pracujete v menších krocích, než byste i v bujné fantazii považovali za rozumné. Na druhou stranu, někteří programátoři se naučí TDD pak se vrátí ke svým dřívějším praktikám a TDD si schovají pro zvláštní příležitosti, kdy běžné programování nepřináší kýžené výsledky.

V programování jistě existují úkoly, které nemůžeme řídit výhradně pomocí testů (nebo alespoň zatím nemůžeme). Například bezpečnostní programy a součinnost jsou dvě témata, kde TDD nemůže paušálně prokázat, že bzlo dosaženo cílů programu. Ačkoli je pravda, že bezpečnost spoléhá na naprosto bezchybný kód, také spoléhá na lidský úsudek ohledně metod použitých k zabezpečení programu. Problémz přesné součinnosti nelze spolehlivě sledovat pouhým proběhnutím kódu.

Ve většině oblastí však TDD úspěšně použít lze a tato kniha vás to může naučit. Až ji dočtete, měli byste být připraveni

jednoduše začít,
psát automatizované testy,
refaktorovat, a tím svá rozhodnutí přidat jedno po druhém do návrhu.

Tato kniha je rozdělena do tří částí.

Část I: Příklad s penězi

Tato část pracuje s příkladem typického výkonného kódu napsaného pomocí TDD. Tento příklad mnohaměnové aritmetiky mi před léty poskytl Ward Cunningham a já jsem ho od té doby mnohokrát použil. Tento příklad vám umožní naučit se psát testy dříve než kód a organicky rozšiřovat návrh.

Část II: Příklad s xUnit

V této části demonstruji na příkladu vývoje rámce pro automatizované testování vývoj a testování komplikovanější logiky včetně reflexe a výjimek. Tento příklad vám také představí architekturu xUnit, která je základem mnoha testovacích nástrojů orientovaných na programátora. Naučíte se zde programovat v ještě menších krocích než v příkladu prvním, včetně jistých specialitek pro počítačové vědce.

Část III: Vzory pro vývoj řízený testy

Zde najdete vzory pro rozhodování, které testy psát, doporučení jak psát testy s využitím xUnit a návody jak zvolit nejlepší návrhové vzory a refaktorování použité v příkladech.

Když jsem psal tyto příklady, představoval jsem si programování v páru. Jestli se místo bloudění kolem raději nejdříve podíváte do mapy, pak možná raději přejdete přímo ke vzorům ve třet části a příkladů použijete pro ilustraci. Dáváte-li přednost bloudění a až potom se díváte do mapy, kam jste se dostali, potom zkuste pročítat příklady a až budete chtít znát více podrobností o technice, použijte část se vzory jako referenční příručku. Několik recenzentů této knihy přiznalo, že maximum z příkladů vztěžili obvzkle tehdy, když spustili programovací prostředí, zadali kód a spustili testy, jak si přečetli.

Poznámka k příkladům. Oba příklady, to znamená převody mezi několika měnami i estovací rámec, se zdají být snadné. Existují (a viděl jsem je) i komplikované, ošklivé, nepřehledné způsoby řešení týchž problémů. Mohl jsem vybrat jedno z těchto ošklivých, komplikovaných, nepřehledných řešení, abych dal knize nádech "reality". Nicméně mým cílem, a doufám že i vaším cílem, je psát čistý kód, který funguje. Předtím než příklady označíte za příliš jednoduché, věnujte alespoň patnáct vteřin představě světa programování, v němž by všechen kód byl takto jasný a přímý, kde nejsou žádná komplikovaná řešení, pouze očividně komplikované problémy volající po pečlivém zamyšlení. TDD vám může pomoci k přesně takovému pečlivému způsobu myšlení.

Vývoj řízený testy, Obsah | Dr3dweRkZ | Vývoj řízený testy, Poděkování