TDD: Úvod

V pátek ráno přišel vedoucí za Wardem Cunninghamem, aby mu představil Petera, budoucího zákazníka pro produkt WyCash, systém pro správu obligací , který společnost prodávala. Petr řekl: "Funkčnost, se kterou jsem se tady setkal, na mě udělala veliký dojem. Ale všiml jsem si, že pracujete s obligacemi pouze v amerických dolarech. Chystám se založit nový fond pro obchod s obligacemi a můj podnikatelský záměr vyžaduje práci s obligacemi v různých měnách." Vedoucí se obrátil na Warda: "Tak co, zvládneme to?"

To je noční můra každého softwarového návrháře. Pohodlně a úspěšně jste proplouvali s určitými předpoklady. Najednou se všechno změnilo. Ale nebyla to noční můra jen pro Warda. Také vedoucí, zkušený odborní v oblasti vývoje softwaru, si ani trochu nebyl jist, jakou odpověď uslyší.

Malý tým vyvinul WyCash během několika let. Systém uměl zpracovat většinu typů běžných cenných papírů, které se na americkém trhu s cennými papíry vyskytovaly, a dále disponoval několika exotickými nástroji, s nimiž si konkurence neuměla poradit, například se zpracováním smluv o zajištění investic.

Celý systém WyCash byl vvyvinu pomocí objektů a objektové databáze. Skupina zkušených softwarových inženýrů dostala na začátku dolar jakožto základní jednotku pro výpočty. Výsledný objekt Dolar zodpovídal za správné formátování a výpočty.

Posledních šest měsíců Ward a zbytek týmu pomalu zbavovali objekt Dolar vší zodpovědnosti. Numerické třídy Smalltalku se ukázaly pro výpočty zcela dostačující. Celý záludný kód pro zaokrouhlování na tři desetinná místa dosahoval svým způsobem přesných výsledků. Výsledky se postupně zpřesňovaly, a tak komplikované mechanizmy testovacího rámce určeného k testování v určitých mezích tolerance byly postupně nahrazeny přesným srovnáváním očekávaných a skutečných výsledků.

Zodpovědnost za formátování převzaly třídy uživatelského rozhraní.

Jelikož testy vznikly na úrovni tříd uživatelského rozhraní, zvláště pak v rámci sestav (oopsla91), nemusely se tyto testy při každém vylepšení měnit. Po šesti měsících pečlivého redukování příliš mnoho zodpovědnosti pro objekt Dolar nezbylo.

Podobně procházel pomalou proměnou i nejsložitější algoritmus v systému - vážený průměr. V jednom okamžiku bylo v systému roztroušeno mnoho různých variant kódu pro výpočet váženého průměru. Jak se rámec sestav vynořoval z původní změti objektů, bylo zřejmé, že by se našlo centrální umístění pro tento algoritmus, a to v objektu AveragedColumn (sloupec průměr).

A právě k objektu AveragedColumn se nyní Ward obrátil. Pokud by bylo možné počítat vážený průměr ve více měnách, pracoval by s nimi i zbytek systému. Algoritmus byl založen na uchování součtu peněz ve sloupci. Ve skutečnosti byl algoritmus natolik abstraktní, že bylo možné počítat vážený průměr libovolného objektu, který se choval aritmeticky. Takovým příkladem bylo datum.

Víkend uběhl jako obvykle. V pondělí ráno se vedoucí vrátil: "Dokažeme to?"

"Dejte mi ještě jeden den a řeknu vám to s jistotou."

Vážený průměr se počítal pomocí objektu Dolar. Proto aby bylo možné počítat v několika měnách, potřebovali objekt počítající s jednotlivými měnami, něco na zbůsob mnohočlenu. Místo 3x2 a 4y3 by však pracoval s 15 USD a 200 CHF.

Rychlý pokus ukázal, že je možné počítat s obecným objektem Meny místo objektu Dolar a vracet objekt MnohoMeny, když se sčítají dvě rozdílné měny. Vtip spočíval v tom, vytvořit prostor pro nové funkce, aniž by došlo k porušení toho, co již funguje. Co by se stalo, kdyby Ward pouze spustil testy?

Po přidání několika málo neimplementovaných operací do objektu Meny většina testů prošla. Než skončil, všechny testy byly úspěšné. Ward sestavil kód a šel za vedoucím:

"Dokážeme to," řekl sebejistě.

Zamysleme se trochu nad celým příběhem. Během dvou dnů se potenciální trh několikrát rozšířil a hodnota systému WyCash mnohonásobně vzrostla. Avšak schopnost vytvořit tak rychle obchodní hodnotu nebyla náhodná. Podílelo se na ní několik faktorů.

Motivaci ke zvyšování hodnoty vašeho projektu nemůžete pomocí technických prostředků příliš ovlivnit. Naopak metodika a příležitost jsou plně ve vaší kompetenci. Ward a jeho tým vytvořili metodiku a příležitost prostřednictvím kombinace výjimčeného talentu, zkušeností a disciplíny. Znamená to snad, že nejste-li jedním z deseti nejlepších softwarových inženýrů na světě a nemát v bance balík, abyste mohli říci svému nadřízenému, ať jde do háje, zabere vám správný postup tolik času, že je pro vás konec navždy v nedohlednu?

Ne. Rozhodně můžete postavist své projekty tak, abyste mohli dělat zázraky, dokonce i tehdy, jste-li softwarovým inženýrem s průměrnými schopnostmi a občas děláte kompromisy a zjednodušujete si život, když termmíny začínají cenit zuby. Vývoj řízený testy je soubor technik, které může používat každý softwarový inženýr a které podporují jednoduché návrhy a balíky spolehlivých testů. Jste-li génius, tato pravidla nepotřebujete. Jste-li hlupák, pravidla vám nepomohou. Většině z nás mezi těmito dvěma póly mohou následující jednoduchá pravidla pomoci plně rozvinout svůj pracovní potenciál.

Jak to přesně udělat, jemné rozdíly v použití těchto pravidel a kam až můžete dojít používáním těchto pravidel, to vše je obsahem této knihy. Začneme s objektem, který Ward vytvořil ve své hvězdné minutě - penězi více měn.

Vývoj řízený testy, Poděkování | Dr3dweRkZ | Vývoj řízený testy, Část I