Lekce 1 - Úvod do testování softwaru v Javě

Vítejte, všichni pokročilí programátoři, u první lekce online kurzu testování aplikací v Javě. Kurz tvořený zejména na základě praktických zkušeností s projekty většího rozsahu a naučíme se v něm postupně pokrývat kód různými typy testů a tím vytvářet spolehlivé a kvalitní aplikace. Je určený pro všechny, kteří usilují o slušné zaměstnání, kde vás za tyto zkušenosti velmi dobře ohodnotí, nebo kteří mají nějakou svou aplikaci a rádi by ji dále pohodlně rozšiřovali tak, aby se nemuseli bát, že změny kódu rozbijí původní funkčnost.

Budu předpokládat, že znáte:

• Základy programování
• Objektově-orientované programování
• Alespoň Základy návrhu softwaru (budu zde používat termíny jako use case a podobně, tak abychom si rozuměli )

Testování je vlastně takovým čtvrtým bodem osnovy výše, který by měl každý dobrý programátor znát, aby jeho práce za něco stála.

Kdy testovat

Testování se určitě řadí mezi dobré praktiky vývoje softwaru (best practices). Další takovou praktikou je např. programovat objektově, používat vícevrstvou architekturu a podobně. Některé praktiky bychom měli dodržovat opravdu ortodoxně, např. pro psaní neobjektového kódu existuje opravdu jediný důvod a tím je neznalost programátora. Zapouzdřování logiky aplikace do objektů a vrstev znamená pro zkušeného vývojáře minimální zdržení a minimalizuje náklady na rozšiřování a udržování nepřehledné a nerozvrstvené aplikace. Na druhou stranu, některé praktiky vývoje softwaru bychom naopak neměli dodržovat až takto extrémně a mezi ně patří právě testování.

Hned na úvod zmíním, že testování je velmi důležité a v určité části projektu dokonce nepostradatelné. Na druhou stranu, v prvních fázích projektu (a to zejména u start-upů), kdy se hraje na čas, funkčnosti aplikace se často mění, a je třeba co nejdříve spustit, není vůbec dobrý nápad testy psát. Musely by se často měnit, zbytečně by zdržovaly a mohly by poškodit rozjezd. Některým z vás nyní možná bleskla hlavou teorie okolo TDD (Test-Driven Development), která se naopak opírá o neustálé testování úplně všeho. Jako teoretický koncept zní sice hezky, ale v praxi by měl dobrý programátor dokázat myslet i trochu jako manažer a nakládat rozumně s vývojovým budgetem (rozpočtem). Konec konců, i jeho plat vychází z toho jak je aplikace konkurenceschopná. Pokud máte naopak aplikaci, která má již několik stabilních funkcí a chcete ji dále rozšiřovat, bez testů se neobejdete. Testy tedy pokrýváme takové aplikace, které již mají několik stabilních funkčností.

Rozšiřování softwaru

Jakékoli rozšiřování softwaru, pokud jej děláte kvalitně, vždy znamená změnu stávajících funkčností. Do jisté míry může kvalitní analýza a návrh připravit půdu pro budoucí úpravy, ale i když se budete hodně snažit, trh se mění nekontrolovaně a úspěšnou aplikaci bude třeba upravovat ze všech stran. Pokud stávající funkce nebudete upravovat, začne vám vznikat redundantní kód (např. napíšete podobnou metodu znovu, místo abyste jen parametrizovali nějakou, co již aplikace má, přidáváte zbytečně další databázové tabulky místo toho, abyste jen upravili datový model a podobně).

Asi víte, že vyhýbat se úpravě stávajícího kódu aplikace se vůbec nevyplatí, trpěl by tím její návrh a do budoucna by bylo velmi těžké takový slepenec nějak upravovat nebo rozšiřovat, když byste museli změny provádět na několika místech, bloky kódu by se opakovaly a podobně. Došli jsme tedy k tomu, že svou aplikaci budete stále měnit a přepisovat, takto vývoj softwaru prostě vypadá. A kdo potom otestuje, že vše funguje? Člověk? Když jsme došli k tomu, že musíme testovat, zda se předchozí funkčnost novou úpravou nerozbila, povězme si proč nemůže testování provádět člověk.

Proč to nemůže dělat člověk?

Zamysleme se nad naivní představou.

Očekávání

Programátor nebo tester si sedne k počítači a prokliká jednu službu za druhou, jestli fungují. Vezměme si třeba ITnetwork. Tester by se zkusil zaregistrovat, přihlásit se, změnit si zapomenuté heslo, upravit profil, dobít body kreditní kartou... Funkčností (use casů) jsou ve zdejším systému stovky. Jestli vás napadá, že člověk by je testoval hodiny a že proto to necháme udělat stroj, který to udělá pravděpodobně za pár minut, stále nemáte úplně pravdu. Sednout si a den klikat není v zásadě pořád takový problém, testy se píší dlouho, možná by se to ještě i vyplatilo. Ale...

Realita

Představte si, že takto testujete aplikaci, jste někde v polovině testovacího scénáře a naleznete chybu. Nejde napsat komentář k článku např. kvůli změně nějakého validátoru. Chybu opravíte, úspěšně pokračujete až do konce scénáře. Otestovanou aplikaci nasadíte na produkční server a další den vám přijde email, že nejdou kupovat články. Po chvíli zkoumání zjistíte, že oprava, kterou jste provedli, rozbila jinou funkčnost, kterou jste již otestovali předtím. Takto jste mohli přijít i o několik desítek tisíc Kč, než vám chybu někdo nahlásil. A to jsme vůbec nezmínili katastrofické scénáře, kdy by došlo k nějakému úniku dat, zaspamování uživatelů a podobně. Pokud se během testování provede oprava, musíte celý scénář provést od začátku! A že se těch chyb obvykle najde hned několik, celé testování se protáhne až na několik dní klikání. Programátor toto pravděpodobně nevydrží a neprovede testy pečlivě (osobně jsem frustraci z provádění těch samých úkonů stále dokola nikdy nesnesl ), čímž dojde k zanesení chyby na produkci.

A právě proto musí testy provádět stroj, který celou aplikaci prokliká obvykle maximálně za desítky minut a může to dělat znovu a znovu a znovu. Proto píšeme automatické testy, toto vám bohužel většina návodů na internetu neřekne.

Typy testů

Zaměřme se nyní na to, co na aplikaci testujeme. Typů testů je hned několik, obvykle nepokrývají úplně všechny možné scénáře (všechen kód), ale hovoříme o procentuálním pokrytí testy (code coverage), většinou kritických částí aplikace. Čím větší aplikace je, tím více typů testů potřebuje a tím více funkčnosti obvykle pokrýváme. První verze menších aplikací většinou naopak ještě nepotřebují žádné testy nebo jen ty úplně základní, např. aby se do nich dalo registrovat.

Popišme si ty nejzákladnější typy testů:

• Jednotkové testy (Unit testy) - Obvykle testují univerzální knihovny, nepíšeme je pro kód specifický pro danou aplikaci. Jednotkové testy testují třídy, přesněji jejich metody, jednu po druhé. Předávají jim různé vstupy a zkouší, zda jsou jejich výstupy korektní. Nemá úplně smysl pomocí unit-testů testovat, zda metoda obsahující databázový dotaz, která je použita v jednom kontroleru (nebo nějaké jiné řídící vrstvě) vrací co má. Naopak dává velmi dobrý smysl testovat např. validátor telefonních čísel, který používáme na 20 místech nebo dokonce v několika aplikacích. Takový jednotkový test vyzkouší např. 20 různých správných a nesprávných telefonních čísel, jestli validátor opravdu pozná, která jsou validní a která ne. Unit testy jsou tzv. whitebox testy, to znamená, že je píšeme s tím, že víme, jak testovaný kód uvnitř funguje (vidíme dovnitř).
• Akceptační testy - Tento typ testů je naopak úplně odstíněn od toho, jak je aplikace uvnitř naprogramovaná, jsou to tedy blackbox testy (nevidíme dovnitř). Každý test obvykle testuje určitou funkčnost, např. test pro psaní článků by testoval jednotlivé use cases s tím spojené (předat článek ke schválení, schválit článek, zamítnou článek, publikovat článek jako administrátor...). Tyto testy obvykle využívají framework Selenium, který umožňuje automaticky klikat ve webovém prohlížeči a simulovat internetového uživatele, co vaši aplikaci používá. Těmito testy se tedy v podstatě zkouší specifická logika aplikace (databázové dotazy a podobně), testuje se výsledek, který aplikace vygeneruje, ne přímo její vnitřní kód.
• Integrační testy - V dnešní době dosahují aplikace již poměrně vysoké komplexnosti a velmi často bývají rozdělené do několika služeb, které spolu komunikují a jsou vyvíjené zvlášť. Právě integrační testy dohlíží na to, aby do sebe vše správně zapadalo.
• Systémové testy - I když aplikace funguje dobře, na produkčním prostředí podléhá dalším vlivům, se kterými musíme rovněž počítat, např. že by měla zvládat obsluhovat tisíc uživatelů v jeden okamžik. To bychom provedli zátěžovým testem, který spadá mezi systémové testy.
• A mnohé další...

V-model

Úvod do problematiky softwarového testování zakončeme představením tzv. V-modelu. Ten rozšiřuje známý vodopádový model vývoje softwaru, který má následující fáze:

• Analýza požadavků
• High-level návrh
• Detailní specifikace
• Implementace

Jak jistě víte, celý software se již dávno nevyvíjí postupným provedením těchto 4 fází, ale iteračně, tedy prováděním těchto fází v krátkých časových intervalech pro další a další části aplikace. V-model každé z těchto fází přiřazuje testovací fáze (typ testů, o kterých jsme mluvili výše):

Vidíme, že název v-modelu je odvozen z podoby s písmenem V. Po implementaci unit testy ověříme detailní specifikaci, integračními testy high-level návrh a akceptačními testy zda fungují všechny use casy. V-model se někdy dělá ještě o několik pater vyšší, pokud je aplikace opravdu rozsáhlá a vyžaduje více typů testů, např. ještě testy systémové).

V příští lekci, Testování v Javě - První unit test v JUnit, se naučíme programovat unit testy, což jsou ty nejjednodušší testy, které ověřují funkčnost vnitřních knihoven (jednotek) a obvykle s nimi začínáme při pokrývání aplikace testy.