Lze automatizovat testování aplikací WPF a WinForms?
Aplikace WPF a WinForms lze automatizovaně testovat, pokud jejich ovládací prvky poskytují dostatek stabilních informací. Test nemusí klikat podle obrázku ani polohy na obrazovce. Před vytvořením celé sady je však důležité ověřit konkrétní aplikaci, zejména vlastní tabulky, grafy a starší komponenty.
Proč zůstává velká část opakovaných kontrol ruční
Desktopové procesy bývají dlouhé a závisejí na stavu počítače, lokálních souborech nebo databázi. Před releasem proto lidé opakovaně procházejí stejné formuláře, při nedostatku času však zkrátí seznam na okolí poslední změny. Chyba se potom může projevit ve zdánlivě nesouvisející části aplikace.
První pokus o automatizaci často používá záznamník kliknutí. Sada funguje na počítači autora, ale začne selhávat při jiném rozlišení nebo po úpravě rozložení. Problémem není samotný desktop, ale způsob identifikace prvků a nepřipravené testovací prostředí.
Jak funguje Windows UI Automation
Microsoft UI Automation poskytuje rozhraní, přes které testovací nástroj zkoumá a ovládá prvky aplikace. WPF standardně vytváří pro ovládací prvky takzvané automation peers; WinForms může podle typu prvku využívat UI Automation nebo klasické rozhraní Win32.
Test tak může vyhledat textové pole podle typu, názvu a identifikátoru namísto pevných souřadnic. To zvyšuje odolnost vůči běžným změnám vzhledu, nikoli však vůči každé změně struktury. Vlastní komponenty musí potřebné vlastnosti zpřístupnit a AutomationId je třeba posuzovat ve správném okně nebo kontejneru.
Pro implementaci se často hodí pywinauto v Pythonu nebo FlaUI v .NET. Rozdíly a kritéria výběru rozebíráme v porovnání pywinauto nebo FlaUI.
Od technického posouzení k první sadě
Spolehlivý postup má čtyři kroky:
- Inspekce rozhraní. Zkontrolujeme, které prvky nástroj vidí a jaké vlastnosti poskytují.
- Pilotní scénář. Vybereme důležitý proces s běžnými i složitějšími prvky a ověříme ho od vstupu až po výsledek.
- Stabilní prostředí. Připravíme známá testovací data, účty, soubory a způsob obnovy po běhu.
- Udržitelná architektura. Přístupy k oknům a prvkům soustředíme do společných komponent a testy čekají na stav aplikace, nikoli na pevně stanovený čas.
Grafické testy potřebují relaci Windows, ve které lze aplikaci skutečně spustit. Lokální počítač, virtuální stroj i CI jsou možné, runner je však třeba připravit podle oprávnění, obrazovky, paralelního běhu a závislostí aplikace. Frekvenci potom nastavíme podle délky a rizika sady.
Na co si dát pozor
UI Automation není zárukou pro každý vlastní prvek. Pokud inspekce neukáže smysluplnou strukturu, může být nutné doplnit identifikátory nebo podporu přístupnosti ve vývojovém kódu. Přístup ke zdrojovému kódu není vždy podmínkou pilotu, někdy je však malá úprava nejlevnější cestou ke stabilním testům.
Co tím získáte
Opakovatelné scénáře zkrátí ruční kontroly před releasem a poskytnou týmu stejnou kontrolu po každé relevantní změně. Testeři mohou více času věnovat průzkumnému testování, novým funkcím a situacím, které nelze jednoduše předepsat.
Pilot zároveň ukáže skutečnou návratnost ještě před investicí do celé sady. Budete vědět, které obrazovky jsou připravené na automatizaci, jaké technické úpravy potřebují a které kontroly je rozumnější provádět ručně.
Další krok
Vyberte jeden kritický scénář, který tým opakuje před každým releasem, a ověřte jeho prvky inspekčním nástrojem. Pokud pilot projde stabilně při několika opakováních, rozšiřte sadu podle obchodního rizika. U kombinovaného produktu lze samostatně posoudit také automatizaci webové části.