1. diel - Úvod do testovania webových aplikácií v PHP

Vitajte, všetci pokročilí programátori, u prvej lekcie online kurzu testovanie aplikácií v PHP. Kurz je tvorený najmä na základe praktických skúseností s projektmi väčšieho rozsahu a 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. Je určený pre všetkých, ktorí sa usilujú o slušné zamestnanie, kde vás za tieto skúsenosti veľmi dobre ohodnotí, alebo ktorí majú nejakú svoju aplikáciu a radi by ju ďalej pohodlne rozširovali tak, aby sa nemuseli báť, že zmeny kódu rozbijú pôvodnej funkčnosť.

Budem predpokladať, že poznáte:

• základy programovania
• Objektovo-orientované programovanie
• Aspoň Základy návrhu softvéru (budem tu používať termíny ako use case a podobne, tak aby sme si rozumeli )

Testovanie je vlastne takým štvrtým bodom osnovy vyššie, ktorý 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 (best practices). Ďalšia touto praktikou je napr. Programovať objektovo, používať viacvrstvovú architektúru a podobne. Niektoré praktiky by sme mali dodržiavať naozaj ortodoxne, napr. Pre písanie neobjektového kódu 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árov minimálnu zdržanie a minimalizuje náklady na rozširovanie a udržiavanie neprehľadné a nerozvrstvené aplikácie. Na druhú stranu, niektoré praktiky vývoja softvéru by sme naopak nemali dodržiavať až takto extrémne a medzi ne patrí práve testovania.

Hneď na úvod spomeniem, že testovanie je veľmi dôležité a v určitej časti projektu dokonca nepostrádateľné. Na druhú stranu, v prvých fázach projektu (a to najmä u start-upov), kedy sa hrá na čas, funkčnosti aplikácie sa často mení, a je potrebné čo najskôr spustiť, nie je vôbec dobrý nápad testy písať. Museli by sa často meniť, zbytočne by spomaľovali a mohli by poškodiť rozjazd. Niektorým z vás teraz možná blysla hlavou teórie okolo TDD (Test-Driven Development), ktorá sa naopak opiera o neustále testovaní ú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 BUDG (rozpočtom). Koniec koncov, aj jeho plat vychádza z toho ako je aplikácia konkurencieschopná. Ak máte naopak aplikáciu, ktorá má už niekoľko stabilných funkcií a chcete ju ďalej rozširovať, bez testov sa nezaobídete. Testy teda pokrývame také aplikácie, ktoré už majú niekoľko stabilných funkčnosťou.

Rozširovanie softvéru

Akékoľvek rozširovanie softvéru, ak ho robíte kvalitne, vždy znamená zmenu existujúcich funkčnosťou. Do istej miery môže kvalitné analýza a návrh pripraviť pôdu pre budúce úpravy, ale aj keď sa budete veľmi snažiť, trh sa mení nekontrolovane a úspešnú aplikáciu bude treba upravovať zo všetkých strán. Ak existujúce funkcie nebudete upravovať, začne vám vznikať redundantný kód (napr. Napíšete podobnú metódu znova, namiesto aby ste len parametrizovali nejakú, čo už aplikácia má, pridávate zbytočne ďalšie databázové tabuľky namiesto toho, aby ste len upravili dátový model a podobne).

Asi viete, že 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ý zlepenec nejako upravovať alebo rozširovať, keď ste museli zmeny vykonávať na niekoľkých miestach, bloky kódu by sa opakovali a podobne. Došli sme teda k tomu, že svoju aplikáciu budete stále meniť a prepisovať, takto vývoj softvéru jednoducho vyzerá. 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.

Prečo to nemôže robiť človek?

Zamyslime sa nad naivné predstavou.

Očakávania

Programátor alebo tester si sadne k počítaču a preklikne jednu službu za druhou, č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 (use časov) sú v tunajšom systému stovky. Ak vás napadá, že človek by ich testoval hodiny a že preto to necháme urobiť stroj, ktorý to urobí pravdepodobne za pár minút, stále nemáte úplne pravdu. Sadnúť si a deň klikať nie je v zásade stále taký problém, automatické testy sa píšu dlho, možno by sa to ešte aj vyplatilo. Ale ...

Realita

Predstavte si, že takto testujete aplikáciu, ste niekde v polovici testovacieho scenára a nájdete chybu. Nejde napísať komentár k článku, napr. Kvôli zmene nejakého validátora. Chybu opravíte, úspešne pokračujete až do konca scenára. Otestovanú aplikáciu nasadíte na produkčný server a ďalší deň vám príde email, že nejdú kupovať články. Po chvíli skúmaní zistíte, že oprava, ktorú ste vykonali, rozbila inú funkčnosť, ktorú ste už otestovali predtým. Takto ste mohli prísť aj o niekoľko desiatok tisíc Sk, než vám chybu niekto nahlásil. A to sme vôbec nespomenuli katastrofické scenáre, kedy by došlo k nejakému úniku dát, zaspamování používateľov a podobne. Ak sa počas testovania vykoná oprava, musíte všetky scenáre vykonať od začiatku! A že sa tých chýb zvyčajne nájde hneď niekoľko, celé testovanie sa pretiahne až na niekoľko dní klikanie. Programátor toto pravdepodobne nevydrží a nevykoná testy starostlivo, čím dôjde k zaneseniu chyby na produkciu (osobne som frustráciu z vykonávania tých istých úkonov stále dokola nikdy nezniesol ).

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

Typy testov

Zamerajme sa teraz na to, čo na aplikáciu testujeme. Typov testov je hneď niekoľko, zvyčajne nepokrývajú úplne všetky možné scenáre (všetok kód), ale hovoríme o percentuálnom pokrytí testy (code coverage), väčšinou kritických častí aplikácie. Čím väčšia aplikácie je, tým viac typov testov potrebuje a tým viac funkčnosti obvykle pokrývame. Prvá verzia menších aplikácií väčšinou naopak ešte nepotrebujú žiadne testy alebo len tie úplne základné, napr. Aby sa do nich dalo registrovať.

Popíšme si tie najzákladnejšie typy testov:

• Jednotkové testy (Unit testy) - Zvyčajne testujú univerzálne knižnice, nepíšeme je pre kód špecifický pre danú aplikáciu. Jednotkové testy testujú triedy, presnejšie ich metódy, jednu po druhej. Odovzdávajú im rôzne vstupy a skúša, či sú ich výstupy korektné. Nemá úplne zmysel pomocou unit-testov testovať, či metóda obsahujúci databázový dotaz, ktorá je použitá v jednom kontroleru (prezentery, nejaké riadiace vrstve) vracia čo má. Naopak dáva veľmi dobrý zmysel testovať napr. Validátor telefónnych čísel, ktorý používame na 20 miestach alebo dokonca v niekoľkých aplikáciách. Takýto jednotkový test vyskúša napr. 20 rôznych správnych a nesprávnych telefónnych čísel, či validátor naozaj spozná, ktorá obsahuje bezchybné a ktorá nie. Unit testy sú tzv. Whitebox testy, to znamená, že je píšeme s tým, že vieme, ako testovaný kód vnútri funguje (vidíme dovnútra).
• Akceptačné testy - Tento typ testov je naopak úplne odtienený od toho, ako je aplikácia vnútri naprogramovaná, sú to teda blackbox testy (nevidíme dovnútra). Každý test zvyčajne testuje určitú funkčnosť, napr. Test pre písanie článkov by testoval jednotlivé use cases s tým spojené (odovzdať článok na schválenie, schváliť článok, zamietnu článok, publikovať článok ako administrátor ...). Tieto testy zvyčajne využívajú framework Selenium, ktorý umožňuje automaticky klikať vo webovom prehliadači a simulovať internetového užívateľa, čo vašu aplikáciu používa. Týmito testami sa teda v podstate skúša špecifická logika aplikácie (databázové dotazy a podobne), testuje sa výsledok, ktorý aplikácia vygeneruje, nie priamo jej vnútorné kód.
• Integračné testy - V dnešnej dobe dosahujú aplikácie už pomerne vysoké komplexnosti a veľmi často bývajú rozdelené do niekoľkých služieb, ktoré spolu komunikujú a sú vyvíjané zvlášť. Práve integračné testy dohliada na to, aby do seba všetko správne zapadalo.
• Systémové testy - Aj keď aplikácia funguje dobre, na produkčnom prostredí podlieha ďalším vplyvom, s ktorými musíme tiež počítať, napr. Že by mala zvládať obsluhovať tisíc užívateľov v jeden okamih. To by sme vykonali záťažovým testom, ktorý spadá medzi systémové testy.
• A mnohé ďalšie ...

V-model

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

• analýza požiadaviek
• High-level návrh
• Detailné špecifikácie
• implementácia

Ako iste viete, celý softvér sa už dávno nevyvíja postupným vykonaním týchto 4 fáz, ale iteračné, teda vykonávaním týchto fáz v krátkych časových intervaloch pre ďalšie a ďalšie časti aplikácie. V-model každej z týchto fáz priraďuje testovacej fázy (typ testov, o ktorých sme hovorili vyššie):

Vidíme, že názov v-modelu je odvodený z podoby s písmenom V. Po implementácii unit testy overíme detailnú špecifikáciu, integračnými testy high-level návrh a akceptačnými testami či fungujú všetky use casy. V-model sa niekedy robí ešte o niekoľko poschodí vyššie, ak je aplikácia naozaj rozsiahla a vyžaduje viac typov testov, napr. Ešte testy systémové).

V budúcej lekcii, Úvod do unit testov v PHP a inštalácia PHPUnit , sa naučíme programovať unit testy, čo sú tie najjednoduchšie testy, ktoré overujú funkčnosť vnútorných knižníc (jednotiek) a zvyčajne s nimi začíname pri pokrývaní aplikácie testy.