Test Driven Development (TDD): Výhody, principy a praktický příklad vývoje řízeného testy

Jedním z nejmodernějších přístupů k vývoji je takzvaný „Test driven development“ nebo také TDD.
O co se ale jedná? Jaké jsou výhody oproti starému dobrému vývoji? Na tyto otázky Vám zodpovíme v tomto článku.

TDD

Nejjednodušší je pouze přeložit název a říct, že se jedná o vývoj řízený testy. Ale co to znamená?
Co to je test? Test je kus kódu, jehož úkolem je zjistit, jestli daný blok funguje tak jak má. Nejčastěji manuálně vymyslíme, jakou hodnotu by měl tento blok vracet, poté napíšeme test, který zkontroluje, že s naším vstupem nám tuto hodnotu opravdu vrátí. Jestliže ji nevrátí – Vrátí jinou, někde spadne, nebo nastane jiná chyba, test selže.

Co znamená selhávající test?

Selhávající test je pro nás to stejné, co chybová hláška při kompilaci – někde je chyba. Mnohdy nám ji pomůže najít včas a zlehčuje její následnou nápravu.
Ale to není jediný účel kterému selhávající testy slouží. Slouží i jako hlavní hnací síla TDD.

Jak probíhá vývoj?

V TDD se jako všude začíná analýzou daného problému, následným vypracováním řešení a v neposlední řadě jeho napsáním.
Právě v psaní se TDD liší od ostatních způsobů vývoje, protože je celé hnáno selhávajícími testy, má totiž několik zásad:

• Piš pouze kód, který souvisí s opravou selhávajícího testu.
• Nepiš delší testy, než co je nutné aby selhaly.
• Nepiš více kódu, než co je potřeba pro projití testu.

Může to znít zvláštně, ale správně by měl být první test napsán dříve, než je vůbec vytvořen soubor, který obsahuje testovaný blok. Chyby v kompilaci přece jen znamenají selhání testu, což z počátku chceme.
Jakmile máme tento selhávající test, napíšeme kód se kterým test projde.
Pozor! Je důležite psát testy před kódem, testy napsané až po kódu nemusí být kompletní!
Kdybychom tedy chtěli vyvinout funkci, která sečte dvě čísla, mohl by náš proces vypadat následovně:

1. Napíšeme test, který se ujistí, že funkce existuje.

function additionTest(){
  console.assert(addNumbers(2, 3) === 5, "Test failed");
}

Metoda console.assert() kontroluje, jestli první argument je/je vyhodnocen jako true, jestliže ne, vyhodí error a hlášu, kterou dostala jako druhý argument. Zde by program spadl na tom, že addNumbers() není definováno. My chceme test projít, takže jí musíme co nejjednodušeji implementovat.

2. Napíšeme tak málo kódu, jak je fyzicky možné, abychom test prošli.

function addNumbers(a: number, b: number): Number {
  return 5;
}

function additionTest(){
  console.assert(addNumbers(2, 3) === 5, "Test failed");
}

Skvěle, nyní jsou všechny testy zelené – funkční. Takže jsme splnily náš úkol.
Ne tak úplně, pozornější si všimli, že funkce „addNumbers()“ nedělá vůbec to, co bychom chtěli aby dělala. Poté, co napíšeme tolik kódu, aby testy prošly, se přesouváme do fáze refactoringu – kontrolujeme, jestli je kód napsaný čistě, nebo jestli je co zlepšit. Tady není, jdeme tedy psát další selhávající test.

3. Donutíme se napsat funkci pořádně

function addNumbers(a: number, b: number): Number {
  return 5;
}

function additionTest(){
  console.assert(addNumbers(2, 3) === 5, "Test failed");
  console.assert(addNumbers(3, 3) === 6, "Test failed");
}

Najednou nám selhává test, takže musíme zase jít psát kód.

function addNumbers(a: number, b: number): Number {
  return a + b;
}

function additionTest(){
  console.assert(addNumbers(2, 3) === 5, "Test failed");
  console.assert(addNumbers(3, 3) === 6, "Test failed");
}

Krása, všechno svítí zeleně, refactoring není potřeba, splnili jsme svou úlohu.

Proč TDD?

Proč tedy vlastně využívat TDD, když musíme psát dvojnásobek kódu (testy a produkční kód)?
Na jednoduchých aplikacích jako je tato, to nejde vidět, ale kód časem hnije.
Hnije protože se nikdo neodváží jej upravovat, udržovat, kdykoliv někdo něco změní, může to rozbít spoustu věcí okolo a nikdo si není jistý kdy se nějaká tato chyba ukáže. U TDD rozběhneme po změně testy a ihned vidíme, jestli se něco nerozbilo. Když jsou testy zelené, můžeme kód vydat do produkce.

Závěr

TDD je skvělý nástroj k psaní kódu, který vydrží. Převzít ve firmě po svém předchůdci kód bez testů je nespočetněkrát hororovější zážitek než kdyby byl tento kód plně pokryt testy. Čas, který ztratíme psaním testů, se nám mnohokrát vrátí v úsporách při debugování.
Takže pokud jste ještě TDD nevyzkoušeli, je nejvyšší čas s ním začít.