Nyní bychom si mohli říct, co vlastně stojí z mého pohledu za to, aby bylo pokryto unit testy.
V některém ze svých zdrojů jsem se dočetl, že vývojář, který píše při vývoji unit testy je zhruba o 20% pomalejší než vývojář, který je nepíše. Podle mě tomu tak ale opravdu být nemusí. Vývojář si jen musí určit správné priority pro to, který kód stojí za unit test a který ne.
Jak jsem psal již v prvním článku, největší výhodou maximálního pokrytí unit testy je pocit jistoty, který vývojář může mít při psaní či měnění existujícího kódu. Opravdu je ale vždy taková jistota potřebná? Zastánci TDD budou argumentovat grafem z knihy Roberta C. Martina – Clean Code, který říká, že čím více se píše kód, který není čistý, tím více klesá produktivita týmu. A má samozřejmě pravdu. Pokud nevidíte souvislost mezi čístým kódem a unit testy, nechte mě ji vysvětlit.
Čím méně unit testů, tím menší sebevědomí kód refaktorovat. Čím méně kód refaktorujeme, tím více vzniká nečistý kód. Čím méně je kód nečistý, tím.. viz graf. Podle Roberta jediná možnost, jak mít rychlý vývoj je, mít ho pomalý. Kdybychom vyvíjeli rychle, tak nás stejně v budoucnosti zpomalí.
Opět si myslím, že v tom má naprostou pravdu. Musíme si ale nalít čistého vína a přiznat si, že mnoho z nás tohle svým zákazníkům a nadřízeným jen tak nevysvětlí. Doba je uspěchaná, každá firma začíná být velice závislá na svých softwarech a potřebují je co nejrychleji. Pojďme teda si určit hranici.
Prvně se musíme zeptat sami sebe nebo týmu, jak moc velké můžou být následky, když funkcionalita aplikace přestane fungovat jakýmkoliv způsobem. Které části projektu jsou kritické a musí fungovat na 100%. Pokaždé se snažte přemýšlet, jestli můžete pro část aplikace unit test vynechat.
Jak poznám část aplikace, kterou nemusím unit testy pokrýt?
To už musí vývojář poznat sám. Pár příkladných tipů bych ale pro vás měl.
- V codebase mám podobný kód, který unit testy má. Pokud píšete už podruhé seřazení položek objednávky, je potřeba psát na to unit test, i když se lpouze iší cílové DTO(Data transfer object) na které je výsledek dotazu mapován?
- Opravdu bude velký problém, když budou položky objednávky v gridu špatně seřazeny? Jaké jsou následky chybného řazení položek?
- Nepokrývají mi tohle chování už UI testy? Pokud na vašem projektu existují UI testy, které vám řeknou, že po této akci tlačítko zůstalo aktivní, i když nemělo, není potřeba psát unit test.
- Stojí tento kód za unit test když vím, že bez tohoto kódu bude chyba ihned zjevná v rámci celé aplikace? Mějme například servisu, která slouží k otevírání oken v mé WPF aplikaci. Taková servisa otevírá každé okno v mé aplikaci. Opravdu musí existovat unit test na to, že do okna s přehledem položek objednávky dorazilo ID objednávky jako parametr v pořádku?
Závěr
Piště unit testy pro kritické funcionality Vaší aplikace. To je bez debat. Ostatní funkce buď nebudou takové terno, když přestanou na pár hodin fungovat nebo nejsou klíčová pro zákazníkův bussiness. Slovo bussiness je zde hodně důležité. Pokud chcete ještě v analýze poznat, která část si zaslouží unit testy, tak slovo bussiness s ním bude velmi spojováno. Například spojení Bussiness rule.