Asi před rokem jsem se seznámil s Unit testy a automatickým testováním kódu. Objevil jsem TDD (Test Driven Development) a s nadšením techniku začal používat. Tato disciplína vývoje si zakládá na jednoduché filozofii tří pravidel:
1. Není dovoleno psát žádný produkční kód, dokud není selhávající test průchozím.
2. Není dovoleno psát více unit testů, dokud existují selhávající testy; a selhání kompilace je také selhání.
3. Není dovoleno psát více produkčního kódu, než je kód, dostačující k tomu, aby test prošel.
Vlastními slovy bych techniku popsal takto: napíšete unit test, který selhává a přitom vytvoříte produkční kód jenom takový, aby byl kód zkompilovatelný. Této fázi se říká „RED“. Poté přejdete k produkčnímu kódu a uděláte co nejmenší úpravy, aby test prošel. Této fázi se říká „GREEN“. Třetí fáze se týká refaktoringu vytvořeného kódu a ano, vývojář by měl refaktorovat i kód unit testů. Pro lepší pochopení doporučím shlédnout přednášky o TDD, například zde.
TDD jsem si přivlastnil za svou a měl jsem velká očekávání. Velkým zastáncem a ne-li zakladatelem této techniky je můj oblíbený Robert C. Martin, kterého můžete slyšet na mnou uvedeném odkaze. Jeho přednášky na youtube jsou opravdu velmi inspirativní. Náš obor bere velmi vážně a požaduje od vývojářů profesionalitu. Proto se mu TDD hodí skvěle do jeho filozofie. TDD Vám zajišťuje vysoko procentní pokrytí produkčního kódu unit testy. Uncle Bob ve svých knihách a přednáškách vysvětluje, že vývojář má největší strach ze změny existujícího kódu, jelikož by mohl rozbít jeho funkčnost. Pokrytí unit testy nám má dát jistotu, že nic nerozbijeme při přidání nových funkcí či při refaktorování kódu.
Taková jistota je opravdu k nezaplacení, ale jedná se o techniku velmi náročnou na vývojářův čas. Po dvou měsících TDD v praxi jsem ztratil osobní disciplínu a na unit testy naprosto zanevřel. Bylo to způsobeno tím, že jsem byl opravdu neuvěřitelně pomalý a jakákoliv změna produkčního kódu vyžadovala nutné změny v kódu testů. Od té doby jsem udržoval pouze existující testy a nevytvářel nové.
Po měsíci jsem se opět nad svým problémem zamyslel a chtěl jsem najít odpovědi. Opět jsem začal sledovat přednášky od Roberta C. Martina o technice TDD a ty ve mě znovu evokovaly pocit, že tato technika je ta správná cesta. Začal jsem opět nový kód pokrývat testy. Tentokrát jsem se ale nedržel striktně pravidel. Prvně jsem tzv “na hrubo” napsal produkční kód. Škaredý, absolutně mimo techniky Clean Code, ale funkční. Poté jsem ho pokryl testy. Nyní jsem měl před sebou kód, který jsem chtěl refaktorovat a vytvořit pěkný, dobře čitelný kód.
Udělám změnu produkčního kódu. Upravím lehce testy. Pustím je. Super, vše zelené. Udělám další změny. Musím přenastavit několik mocků, ale po chvilce opět vše zelené. Je čas na větší várku úprav produkčního kódu. Podívám se do projektu s testy. Nezkompilovatelné. Upravím kód, aby byl kompilovatelný. Polovina testů vrací NullReferenceException. Zdebuguji testy a opravím. V tu chvíli si uvědomuji, že jsem opět tam, kde jsem nechtěl být. Nyní sice nemám test na každý detail, protože jsem prvně psal produkční kód a až poté udělal testy. Ale opět jsem se musel velmi starat o testovací kód, což je opět časově náročné a žádná zábava.
Opět jsem si potvrdil to, že unit testování je samo o sobě časově velmi náročné a opět jsem na nějaký čas přestal psát testy pro nový kód. Uběhl čas a problém mi dále vrtal hlavou. Rozhodl jsem se pro větší studii nauky o unit testování. Nyní mohu říct, že mi unit testy zrychlují implementaci. Zlepšil jsem si způsob psaní unit testů. V nadcházejících článcích bych Vám chtěl přiblížit techniky, které pro unit testování aplikuji. Články budou předpokládat základní zkušenost a znalost unit testování.