1. diel - Úvod do testovania softvéru v Kotlin

Vitajte, všetci pokročilí programátori, u prvej lekcie tutoriálu testovanie aplikácií v Kotline. Kurz je tvorený najmä na základe praktických skúseností s projektmi väčšieho rozsahu. Naučíme sa v ňom postupne pokrývať kód rôznymi typmi testov a tým vytvárať spoľahlivé a kvalitné aplikácie. Nadobudnuté znalosti sa hodia na získanie veľmi dobrej pracovnej pozície aj pri tvorbe vlastných aplikácií, ktoré je možné potom pohodlne rozširovať bez obáv, že zmeny kódu rozbijú pôvodnú funkčnosť.

Minimálne požiadavky kurzu

Kurz predpokladá dobrú znalosť jazyka Kotlin, najmä:

• základná konštrukcia a
• objektovo orientované programovanie
• ďalej základnú znalosť návrhových vzorov

Testovanie je vlastne takým štvrtým bodom osnovy vyššie. Všetky štyri body by mal každý dobrý programátor poznať, aby jeho práca za niečo stála.

Kedy testovať

Testovanie sa určite radí medzi dobré praktiky vývoja softvéru, tzv. best practices. Ako ďalšie uveďme objektové programovanie či použitie viacvrstvovej architektúry. Niektoré praktiky by sme mali dodržiavať skutočne ortodoxne. Na písanie neobjektového kódu totiž existuje naozaj jediný dôvod a tým je neznalosť programátora. Zapúzdrovanie logiky aplikácie do objektov a vrstiev znamená pre skúseného vývojára minimálne zdržanie a minimalizuje náklady na rozširovanie a udržiavanie neprehľadnej a nerozvrstvenej aplikácie.

Na druhú stranu, niektoré praktiky vývoja softvéru by sme naopak nemali dodržiavať až takto extrémne. Medzi ne patrí práve testovanie. Hneď na úvod spomeniem, že testovanie je veľmi dôležité av určitej časti projektu dokonca nenahraditeľné. V prvých fázach projektu, a to najmä u start-upov, kedy sa hrá na čas a funkčnosti aplikácie sa často menia, nie je vôbec dobrý nápad testy písať.

V tomto prípade je potrebné čo najskôr aplikáciu spustiť. Testy by sa navyše museli často meniť, zbytočne by zdržiavali a mohli by poškodiť rozjazd.

Niektorým z vás teraz možno bleskla hlavou teórie okolo TDD (Test-Driven Development), ktorá sa naopak opiera o neustále testovanie úplne všetkého. Ako teoretický koncept znie síce pekne, ale v praxi by mal dobrý programátor dokázať myslieť aj trochu ako manažér a nakladať rozumne s vývojovým rozpočtom.

Pokiaľ máme naopak aplikáciu, ktorá má už niekoľko stabilných funkcií a chceme ju ďalej rozširovať, bez testov sa nezaobídeme. Testy teda pokrývame také aplikácie, ktoré už dosiahli určitú stabilitu.

Rozširovanie softvéru

Akékoľvek kvalitné rozširovanie softvéru vždy znamená zmenu existujúcich funkčností. Do istej miery môže kvalitná analýza a návrh pripraviť pôdu pre budúce úpravy. Aj keď sa však budeme veľa snažiť, trh sa mení nekontrolovane a úspešnú aplikáciu bude treba upravovať zo všetkých strán. Ak by sme existujúce funkcie neupravovali, začal by nám vznikať redundantný kód.

Takto napríklad napíšeme podobnú metódu znova a nevyužijeme existujúcu s upravenými parametrami. Alebo pridáme zbytočne ďalšie databázové tabuľky namiesto toho, aby sme len upravili dátový model a podobne.

Vyhýbať sa úprave existujúceho kódu aplikácie sa vôbec neoplatí, trpel by tým jej návrh a do budúcnosti by bolo veľmi ťažké takýto zlepenec nejako upravovať alebo rozširovať. Potom by sme museli zmeny vykonávať na niekoľkých miestach, bloky kódu by sa opakovali a došli by sme najskôr k záveru, že takú aplikáciu nemožno ďalej udržiavať a rozširovať. Takto vývoj softvéru jednoducho nevyzerá.

A kto potom otestuje, že všetko funguje? Človek? Keď sme došli k tomu, že musíme testovať, či sa predchádzajúca funkčnosť novou úpravou nerozbila, povedzme si prečo nemôže testovanie vykonávať človek.

Úskalia manuálneho testovania

Predstavme si nasledujúci scenár.

Očakávania

Programátor alebo tester si sadne k počítaču a preklikne jednu službu za druhú, či fungujú. Zoberme si napríklad ITnetwork. Tester by sa skúsil zaregistrovať, prihlásiť sa, zmeniť si zabudnuté heslo, upraviť profil, dobiť body kreditnou kartou... Funkčnosťou (tzv. use cases) sú v tunajšom systéme stovky. Človek by ich testoval hodiny a stroj to najskôr urobí za pár minút.

Toto ale nie je hlavný dôvod, prečo nemôže testovanie vykonávať človek. Sadnúť si a deň klikať nie je v zásade stále taký problém, testy sa píšu dlho, možno by sa to ešte aj vyplatilo. Ale...

Realita

Dajme tomu, že aplikáciu takto testujeme, sme niekde v polovici testovacieho scenára a nájdeme chybu. Nejde napísať komentár k článku napríklad kvôli zmene nejakého validátora. Chybu opravíme a úspešne pokračujeme až do konca scenára. Otestovanú aplikáciu nasadíme na produkčný server a ďalší deň nám príde email, že nejdú kupovať články.

Po chvíli skúmania zistíme, že oprava, ktorú sme vykonali, rozbila inú funkčnosť. Tú sme totiž testovali predtým. Takto by sme mohli prísť aj o niekoľko desiatok tisíc korún, kým nám chybu niekto nahlási. A to sme vôbec nespomenuli katastrofické scenáre, kedy by došlo k nejakému úniku dát, zaspamovaniu používateľov a podobne.

Ak sa počas testovania vykoná oprava, musíme celý scenár vykonať od začiatku!

Chyb sa obvykle nájde hneď niekoľko a celé testovanie by sa takto pretiahlo až na niekoľko dní klikania. Programátor toto pravdepodobne nevydrží a nevykoná testy starostlivo, čím dôjde k zaneseniu chyby na produkciu.

A práve preto musí testy vykonávať stroj, ktorý celú aplikáciu prekliká obvykle maximálne za desiatky minút a môže to robiť znova a znova a znova. Preto píšeme automatické testy. Toto nám však bohužiaľ väčšina návodov na internete nepovie.

Typy testov

Typov automatických testov je hneď niekoľko, obvykle nepokrývajú úplne všetky možné scenáre, ale hovoríme o percentuálnom pokrytí testami (code coverage). Pokrývame nimi najmä kritické časti aplikácie. Čím väčšia aplikácia je, tým viac typov testov potrebuje a tým viac funkčností obvykle pokrývame. Prvé verzie menších aplikácií väčšinou naopak ešte nepotrebujú žiadne testy alebo len tie úplne základné (napr. overujeme, či je možné sa do aplikácie registrovať).

Popíšme si základné typy testov:

• Jednotkové testy (unit testy) zvyčajne testujú univerzálne knižnice. Nepíšeme ich pre kód špecifický pre danú aplikáciu. Testujú triedy, presnejšie ich metódy, jednu po druhej. Odovzdávajú im rôzne vstupy a skúšajú, či sú ich výstupy korektné. Nemá úplne zmysel takto testovať, či metóda obsahujúca databázový dotaz a použitá v jednom kontroléri, vracia, čo má. Naopak dáva veľmi dobrý zmysel testovať napr. validátor telefónnych čísel, ktorý používame na viacerých miestach. Takýto jednotkový test vyskúša napr. dvadsať rôznych správnych a nesprávnych telefónnych čísel a zistí, či ich validátor naozaj rozpozná.

Unit testy sú tzv. whitebox testy, to znamená, že pri ich tvorbe vieme, ako testovaný kód vo vnútri funguje (vidíme dovnútra).

• Akceptačné testy sú naopak úplne odtienené od toho, ako je aplikácia vo vnútri naprogramovaná. Označujeme ich teda ako blackbox testy. Každý test obvykle testuje určitú funkčnosť. Test na písanie článkov napríklad testuje jednotlivé use cases s tým spojené - odovzdanie článku na schválenie, schvaľovanie či zamietnutie článku, publikácia v úlohe administrátora...

Tieto testy obvykle využívajú framework Selenium, ktorý umožňuje automaticky klikať vo webovom prehliadači a simulovať internetového užívateľa. V podstate skúša špecifickú logiku aplikácie (databázové otázky a podobne). Testuje sa výsledok, ktorý aplikácia vygeneruje, nie priamo jej vnútorný kód.

• Integračné testy dohliadajú na to, aby do seba všetko správne zapadalo v aplikáciách s už pomerne vysokou komplexnosťou. Tie veľmi často bývajú rozdelené do viacerých služieb, ktoré spolu komunikujú a sú vyvíjané zvlášť.
• Systémové testy umožňujú kontrolovať ďalšie vplyvy, s ktorými musíme tiež počítať. Aplikácia by mala napríklad zvládnuť obslúžiť tisíc užívateľov v jeden okamih. To by overil záťažový test, ktorý patrí medzi systémové testy.

V-model

Úvod do problematiky softvérového testovania zakončime predstavením tzv. V-modelu. Ten rozširuje známy vodopádový model vývoja softvéru, kam patria nasledujúce fázy:

• analýza požiadaviek,
• high-level návrh,
• detailné špecifikácie a
• implementácia.

Celý softvér sa už dávno nevyvíja postupným prevedením týchto štyroch fáz, ale iteračne. Jednotlivé fázy sa v krátkych časových intervaloch postupne aplikujú na ďalšie časti aplikácie. V-model každej z nich priraďuje testovacia fáza, teda daný typ testov, o ktorých sme hovorili vyššie:

Vidíme, že názov V-modelu je odvodený z podoby s písmenom V. Unit testy overíme detailnú špecifikáciu, integračnými testami high-level návrh a akceptačnými testami zistíme, či fungujú všetky use cases. V-model môže byť o niekoľko poschodí vyšší, pokiaľ je aplikácia naozaj rozsiahla a vyžaduje viac typov testov, napr. spomínané systémové testy.

V budúcej lekcii, Testovanie v Kotline - Prvý unit test pomocou JUnit , sa naučíme programovať unit testy, čo sú tie najjednoduchšie testy, ktoré overujú funkčnosť vnútorných knižníc. Obvykle práve s nimi začíname pri pokrývaní aplikácie testami.