Automatizace funkčních testů - IV.

V dnešním díle miniseriálu o automatizaci testů vám něco řeknu o způsobu, jak testovací nástroje pracují.

Automatizační tooly fungují na principu detekce jednotlivých objektů uvnitř procesu operačního systému, jejich vlastností a podporovaných funkcí. Pro každou technologii volí nástroj jiný způsob "přístupu" k objektu:

• pro .NET aplikace je to nejčastěji využití tzv. reflexe
• pro "legacy" aplikace (vyvíjené třeba ve Visual C++ nebo Delphi) se obvykle jako zdroj doplňkových informací používají "ladící informace" vygenerované kompilátorem (z toho důvodu může být vhodnější automatizovat aplikaci zkompilovanou v módu "debug", nikoliv v "release" - automaty pak toho většinou "vidí víc")
• pro internetové aplikace v prohlížeči se může použít přístup k objektům přes DOM (Document Object Model). 

Pokud nástroj daný ovládací prvek správně "detekuje", můžete používat příslušné vlastnosti/metody/události objektu, které nástroj "vidí". 
Některé nástroje tak mohou volat nejen veřejné, ale dokonce i privátní metody v kódu testované aplikace - takže můžete váš tool pro původně zamýšlené "blackbox testy" použít dokonce i pro "unit testy".
Další nástroje navíc umožňují psát "vlastní kód" ulehčující automatizaci - třeba vytvořit vlastní pluginy do testovacího toolu, nebo přímo využívat funkce uvnitř .NET Frameworku, Java balíčků atd.

Jak to asi může s detekcí komponent v praxi vypadat je zobrazeno na nasledujícím screenshotu.

Kalkulačka v TestComplete

Může se stát, že nástroj danou komponentu "nepodporuje" a tudíž snad kromě "kliků myší na koordináty x,y na obrazovce" nic jiného dělat nemůžete - ty lepší tooly umí využít různé finty na obejití těchto "neznámých" komponent - třeba rozpoznávání znaků (OCR).
Těmto fintám je ale lepší se vyhýbat a používat je pouze "ve stavu nouze", jelikož se pak může snížit robustnost testů (vývojáři třeba změní font na nějaký "umělecký" a můžete být v... nekomfortní situaci).

Nástroj na základě předvolených vlastností pro daný typ ovládacího prvku (třeba "název třídy" + "ID objektu") objekt v procesu jednoznačně identifikuje. Pokročilejší nástroje umožní nejen určit vlastní skupinu předvolených "identifikujících" vlastností, ale třeba i objektu přiřadit vlastní jméno. Tudíž lze docílit něčeho jako "pokud je to Editbox a je čtvrtým ovládacím prvkem na formuláři, bude se jmenovat txtPrijmeni" a následně přes toto jméno můžete k objektu přistupovat v automatizačním kódu.

Problém nastává, pokud třeba objekt neobsahuje takový soubor "jednoznačně identifikujících vlastností", nebo je má nástroj "předvolené špatně" - třeba u internetových aplikací, ne každý element na stránce má své "ID". Tehdy nezbývá nic jiného než domluva s vývojářem - buďto může poradit, které vlastnosti jsou ty "správné", případně může pro účely testování tyto nové vlastnosti do kódu svého produktu přidat.

Pokud najdete více těchto "unikátních vlastností", do detekce zahrňte tu, která se pravděpodobně bude měnit nejméně často, abyste si ušetřili psaní nového kódu při změně testované aplikace. Například je mnohem vhodnější zvolit vlastnost "Name" u prvku Label, než "Caption" (jelikož programátorské ID se pravděpodobně bude měnit méně často, než zobrazený text v daném prvku).

Pár rad na závěr: Správná detekce ovládacích prvků je klíčová pro úspěšnou automatizaci - pokud uděláte špatnou volbu, případná změna bude opravdu hodně pracná. Komunikujte s vývojáři, podle čeho je nejlepší detekovat danou komponentu, pokud si tím nejste jisti. A hlavně - využijte veškerá dostupná "ulehčení", které nástroj podporuje (třeba nahrávání akcí, aliasy...), ušetříte si tím hodně psaní kódu a tím i automatizace vyjde v konečném důsledku levněji.

Příště se můžete těšit na povídání o designu automatizovaných testovacích případů.