Otázku z úvodu bych položil ještě provokativněji: Má smysl automatické testování?
Automatické testy jsou samozřejmou součástí všech kurzů o kvalitě kódů. Naprostá většina webů, které se testování věnují, považují automatické testy za „must to have“ – nezbytnou součást každého softwarového vývoje.
Přednáším a spolupracuji s vývojovými týmy desetiletí a mohu pozorovat i druhou strany – naprostá většina týmů, se kterými jsem pracoval, automatické testování nepoužívá. Nešlo o malé týmy – pracoval jsem pro všech 5 největších českých bank i spolupracoval s velkými dodavateli, kde byly týmy se stovkami programátorů.
Problematické situace, kdy testy selžou
Kdy mají vznikat automatické testy
Ideální stav, který doporučují analytické kurzy je, aby automatické testy psali test analytici, kteří nepíšou kód, ale vycházejí z analýzy.
V praxi toto téměř nikdy není možné. Automatické testy volají funkce systému a testují konkrétní funkce – to samozřejmě není možné vytvořit bez znalosti kódu.
TDD - Test Driven Development
Např. oblíbené TDD – Test Driven Development, tedy programování řízené testy počítá s tím, že programátor nejdříve napíše test a pak kód. Jenomže když programátor napíše kód i test, tak pokud má v logice chybu, udělá ji téměř jistě v kódu i v testu.
Automatické testy kontrolují, že programátor neopakuje stejnou chybu
Další oblíbená rada je, že pokud se nalezne v chování aplikace chyba, má se udělat automatický test, který ji odhalí. Jenomže tento test je s velkou pravděpodobností do budoucna už k ničemu – když je chyb odstraněna, jen málokdy ji udělá programátor znovu. Proč? Protože většina funkcí je v kódu velkých aplikací neměnná i desetiletí.
Správa testů samozřejmě není zadarmo – když v nich bude mnoho testů, které testují kód, na který nikdo nesahá, je s nimi více práce, než užitku.
Automatické testy neověří logické chyby
Velmi častou chybou je chyba v logice. Např. systém nefunguje pro některé typy dat. Samozřejmě se náhodný test může „trefit“ a tuto situaci odhalit, ale týkají se ho oba výše uvedené půroblémy – nesmí ho tvořit programátor a pokud chybu odhalí, tak ji tým opraví a vícekrát už není důvod se jí zabývat.
Systém je na automatické testy příliš složitý
Je snadné pustit testy např. na PHP funkci. Funkci test zavolá, ona něco vrátí a to se ověří. Jenomže chyby, které se špatně hledají, nejsou „v jedné funkci“. Jsou většinou v logice, v náhodných datech, v náhodném chování. V interakci mezi front-endem, back-endem a daty v databázi.
Aby bylo možné automatické testy opakovaně pouštět, je nutné, aby „pod nimi“ byla stejná databáze. Stejné záznamy, stejná logická struktura. Chybu vyplývající např. z toho, že někde se objeví 2 záznamy, které splňují podmínku u které si programátor myslel, že vrátí vždy jeden záznam, nemůže takový test odhalit. Prostě proto, že v testovací databázi nebude.
Kdy tedy mají automatické testy smysl?
Jsou dvě základní situace, kdy mají automatizované testy opravdu smysl.
Používáte základ od jiného dodavatele
Pokud stavíte aplikace na cizích základech, mustíe vždycky počítat s tím, že vám ji nový release těchto základů rozhodí. A je jedno, jestli tím základem je framework (např. náš AyMINE), nebo třeba Navision, nebo cokoli jiného.
Pokud se změní kód, který na který je vaše řešení napojeno, tak opakované testy mohou odhalit, že volané funkce ze základu vrací stále totéž. A pokud ne, je třeba zjišťovat, proč dochází ke změně.
Integrejute řešení z většího týmu
V samotném základu je to jiná varianta předchozího případu – v týmu vám někdo změní něco a někdo jiný s tím nepočítal, takže ve výsledku nejsou součásti kompatibilní.
Můžeme polemizovat, jestli je testování v tomto případě ta správná cesta – efektivní domluva a analýza je určitě lepším řešením, ale v reálu i ta někdy selže. Pak mohou atuomatické testy skutečně pomoci.
Pokud vyvíjíte např. s automatickým / kontinuálním buildováním aplikace z kousků a vyvíjí tým, který se vzájemně nezná a nevidí si vzájemně na stůl, měly by u toho automatické testy vždy být. Jinak se tým utopí v problémech, když někdo udělá změnu, ta systém rozhodí a nikdo nebude vědět, kdo tam co dělal.
Nepřeceňujte automatické testy
I když mají automatické testy své místo, není radno je přeceňovat. Shrňme si, co nemají reálnou šanci odhalit:
- Chyby v logice – je přitom jedno, kdo tu chybu udělal, jestli analytik nebo programátor. Tyto chyby jsou přitom dlouhodobě nejdražší (jejich odstranění je nejnáročnější)
- Vědomé chyby programátora – např. backdoor, zjednodušení případu na běžný případ apod.
- Chyby, které vyvolají reálná data. Jde o variantu chyby v logice ale s tím rozdílem, že chybu často vyvolají data, která logicky nedávají smysl, protože lidé nedělají všechno logicky
- Problémy velkého objemu dat – mnoho testů i případů vypadá jednoduše, ale v reálnu, kdy není 5 ale 5000 objednávek je najednou chování zcela jiné
- Nepřehledné nebo jinak problematického rozhraní – jde v principu o logiku ovládání. Automatické testy nidky nenahradí UX testy (testy užiatelského rozhraní)
- Nedodržení licencí kódu – to je trochu perlička na závěr; protož to automatické testy samozřejmě odhalovat nemohou
Jak si jinak ušetřit práci
Automatické testování není jedinou možností, jak náklady na kvalitu snižovat. Existují i jiné metody, které jsou opomíjené, i když jejich přínos je zcela srovnatelný
- Investovat do nástrojů, které chyby odhalují v běhu. Zejména robustní kód, který sí nechá líbit i hodně hrubé zacházení. Základní programátorské pravidlo, že v každém kódu je chyba, by mělo být mantrou
- S každou zjištěnou chybou investovat do úprav, které umožní podobný tych chyby odhalit co nejsnáze – ideálně tak, aby na ni systém sám upozorňoval. Typickým přikladem tohoto přístupu je kontrola vstupních dat u funkcí. Když si funkce ověřuje, že dostává platná data, okamžitě upozorní na problém, O chybě se pak okmažitě ví.
- Statitcké analýzy kódu. Existuje řada nástrojů pro statické analýzy. Zdaleka nejsou univerzální, ale některé nedostatky mohou odstranit. Kvalitnější analýzu, než automatizované nástroje samozřejmě poskytne schopný kolega nebo i externista, který se nad kódem zamyslí. Možná i v tom bude časem umělí inteligence lepší, ale v roce 2024 to určitě nebude.
- Prohledávání kódu a hledání běžných chyb. Existuje řada nástrojů, které se učí např. na github kódech. Github pak přímo varuje před problémy, ale stejnou funkcionalitu můžete využít i pro vlastní kód. A miochodem, porovnání s github vám pomůže najít i problémy s licencemi.
Zaujaly vás naše zkušenosti?
Jestli vás naše zkušenosti zaujali a chtěli byste jich využít více, můžete využít naše školení o testování, testovací tým i framework pro podnikové aplikace, který vyvíjíme v logice zero failure – netvrdíme, že v něm není žádná chyba, ale že neselže. A to je to, oč běží ne?