Testování desktop aplikací

Jak spouštět testy WPF a WinForms v CI na Windows runneru

Test WPF nebo WinForms může procházet na pracovním počítači a po přesunu do CI, tedy automatizovaného procesu sestavení a kontroly změn, nenajít okno aplikace. Příčinou nemusí být test: desktopové rozhraní potřebuje vhodnou relaci Windows, zatímco CI agent často běží jako služba bez použitelné obrazovky. Článek vysvětluje, jak vybrat runner, připravit relaci a odlišit chybu aplikace od chyby prostředí.

Proč desktopový UI test není obyčejná CI úloha

Unit test nebo API test může běžet bez přihlášeného uživatele. Grafický test však spouští aplikaci, vyhledává okna prostřednictvím Microsoft UI Automation a podle použité knihovny pracuje s fokusem, klávesnicí, myší nebo snímkem obrazovky. Potřebuje proto relaci, ve které je pracovní plocha dostupná způsobem požadovaným konkrétním nástrojem.

Lokální běh tuto podmínku splňuje bez zvláštní konfigurace: uživatel je přihlášený a aplikaci vidí. V CI může runner běžet pod jiným účtem, jako služba Windows, v zamčené relaci nebo bez závislostí nainstalovaných na počítači autora. Nejprve proto ověřujte prostředí a teprve potom upravujte lokátory a čekání v testu.

Hostovaný a vlastní runner neřeší stejnou úlohu

Hostovaný Windows runner je vhodný pro sestavení aplikace, unit testy a další úlohy, které nepotřebují trvale připravenou interaktivní plochu. Například GitHub Actions vytvoří pro každý job nový hostovaný virtuální stroj a po jobu jej zruší. Potřebný software lze během jobu doinstalovat, samotné označení windows-latest však nedokazuje, že konkrétní desktopový nástroj dostane relaci, kterou vyžaduje.

Podmínky se liší také mezi CI platformami. Microsoft u Azure Pipelines uvádí, že viditelné UI testy nejsou podporované na Microsoft-hosted agentech. Pro desktopové testy na self-hosted Windows agentu popisuje interaktivní proces s automatickým přihlášením. Toto tvrzení platí pro uvedenou platformu; u GitHub Actions, GitLabu nebo jiného řešení je nutné ověřit způsob spuštění runneru i testovací knihovny pilotem.

Self-hosted runner dává týmu kontrolu nad Windows, nainstalovanými runtime balíčky, účtem i životním cyklem stroje. Zároveň tým odpovídá za aktualizace, ochranu přístupů, čištění dat a dostupnost runneru. Pro viditelné WPF nebo WinForms testy bývá řízený virtuální stroj praktičtějším základem, není však zárukou stability.

Modelová situace: test selhává jen při nočním spuštění

Tým má test vytvoření objednávky, který na počítači autora projde. Na virtuálním CI stroji jej technik večer rovněž úspěšně spustí přes vzdálenou plochu (RDP). Noční job však skončí hlášením, že tlačítko „Uložit“ neexistuje. Ranní snímek navíc zachytí přihlašovací obrazovku, ne aplikaci.

Takové selhání ještě nepotvrzuje chybný lokátor. Rozhodující otázky znějí: pod jakým účtem runner běžel, ve které relaci se aplikace spustila, co se stalo po odpojení technika a zda byl proces aplikace vůbec viditelný ve stejné relaci jako test. Pokud tým bez kontroly přidá delší čekání nebo automatický retry, může jen zakrýt konfiguraci, která při každém bezobslužném běhu selže stejným způsobem.

Pilot proto musí zahrnovat také skutečný způsob spuštění: naplánovaný start, odpojenou vzdálenou správu, stejný testovací účet a stejný artefakt jako budoucí noční job. Teprve když tento běh projde, má smysl řešit stabilitu jednotlivých prvků aplikace.

Jak připravit Windows runner krok za krokem

1. Ověřte pilot na cílovém stroji

Nejprve na budoucím runneru ručně spusťte jeden reprezentativní scénář. Měl by otevřít aplikaci, pracovat s běžným formulářem i složitějším prvkem a ověřit výsledek. Pokud ještě není potvrzené, že nástroj prvky vidí, pomůže nejprve technické posouzení popsané v článku Lze automatizovat testování aplikací WPF a WinForms?.

2. Použijte vyhrazené a reprodukovatelné prostředí

Zapište verzi Windows, .NET runtime, ovladače, fonty, jazyk, regionální nastavení a všechny služby, na kterých aplikace závisí. Instalujte stejný artefakt, který vznikl v pipeline, ne náhodný vývojářský build. Osobní pracovní počítač je nevhodný základ: jeho aktualizace, dialogy a ruční práce mění stav během testu.

3. Připravte účet a interaktivní relaci

Runner a aplikace musí běžet v relaci, ke které má testovací proces přístup. Pokud platforma a knihovna vyžadují automatické přihlášení, použijte samostatný testovací účet s nejmenšími potřebnými oprávněními a chraňte přístup k virtuálnímu stroji. Heslo neukládejte do repozitáře ani do čitelného skriptu.

Pokud aplikace vyžaduje zvýšená oprávnění, ověřte kompatibilitu úrovně oprávnění testovacího procesu a aplikace. Nevypínejte globálně Řízení uživatelských účtů (UAC) ani jiné ochrany jen proto, aby test prošel. Vhodnější je upravit pilot, účet nebo způsob nasazení a přesně zdokumentovat nezbytná práva.

4. Zabraňte nechtěnému zamčení nebo změně relace

Nastavte prostředí tak, aby plánované zásady uspání, spořič obrazovky nebo interaktivní aktualizace nepřerušily test v dohodnutém okně. Pozor na vzdálenou správu: Microsoft upozorňuje, že běžné odpojení RDP od agenta s automatickým přihlášením může počítač zamknout a UI test může selhat. V dokumentaci Azure uvádí odpojení pomocí tscon; použijte je jen po ověření postupu pro svou platformu a relaci. Alternativou je konzole hypervizoru nebo způsob vzdáleného přístupu, který testovací plochu nezamkne.

5. Obnovujte data a aplikaci před během

Před testem ukončete zbývající procesy z předchozího běhu, nasaďte artefakt a připravte známá data. Po testu odstraňte vytvořené soubory a obnovte databázi nebo uživatelský profil podle dohodnutého postupu. Čistý stav je důležitější než snaha opravit každý pád opakovaným spuštěním.

6. Paralelizujte mezi stroji, ne na jedné ploše

Dva testy na jedné interaktivní ploše si mohou přebírat fokus, zavírat okna nebo používat stejnou schránku. Začněte jedním UI workerem. Pokud potřebujete sadu zrychlit, rozdělte ji mezi izolované virtuální stroje nebo samostatné relace, jejichž podporu jste pro zvolený nástroj ověřili.

7. Uložte důkazy o prostředí i pádu

Ke každému běhu zaznamenejte verzi aplikace, runneru a Windows, rozlišení a měřítko zobrazení. Při pádu uložte log testu a aplikace, snímek obrazovky a podle možností strom UI Automation. Artefakty mohou obsahovat zákaznická data nebo hesla, proto omezte jejich přístup a dobu uchovávání.

Akceptační kritéria pro runner

Připravenost runneru nehodnoťte podle jediného zeleného běhu. Vytvořte krátký infrastrukturní smoke test, který před produktovými scénáři ověří relaci, dostupnost pracovní plochy, spuštění aplikace, verzi artefaktu a přístup k testovacím datům. Pokud tato kontrola selže, pipeline má výsledek zařadit mezi chyby prostředí a produktové testy nespouštět.

Pilot zopakujte v podmínkách, které runner zažije v provozu:

• po restartu virtuálního stroje a automatickém spuštění agenta;
• po nasazení čisté verze aplikace i po její aktualizaci;
• bez otevřeného okna RDP a bez ručního zásahu uživatele;
• se stejným rozlišením, měřítkem, jazykem a regionálním nastavením;
• po neúspěšném testu, aby se potvrdilo ukončení procesů a obnovení dat.

Za úspěch nepovažujte pouze dokončení kroků. Ověřte, že test pracoval se správným buildem, výsledný záznam vznikl v určeném prostředí a další běh začal z čistého stavu. Pokud aplikace vytváří lokální soubor nebo databázový záznam, zkontrolujte jeho obsah přes stabilní rozhraní, ne pouze text potvrzovacího dialogu.

Rozdělte pipeline podle účelu

Praktická pipeline sestaví a podepíše aplikaci na běžném build runneru, potom odešle konkrétní artefakt na vyhrazený Windows UI runner. Krátký smoke balík ověří spuštění, přihlášení a jeden kritický proces. Širší regrese může běžet po důležitém merge, před releasem nebo v noci podle trvání a rizika.

Selhání přípravy prostředí označte jinak než chybu očekávaného chování aplikace. Pokud se nepodařilo přihlásit do relace nebo nainstalovat artefakt, výsledek neříká, že produkt neprošel testem. Toto rozlišení šetří čas při diagnostice a udržuje důvěru v sadu.

Automatické opakování používejte opatrně. Jeden diagnostický opakovaný pokus může ukázat, zda selhání závisí na přechodném stavu, původní výsledek však musí zůstat viditelný. Sledujte samostatně podíl selhání infrastrukturního smoke testu a podíl produktových testů, které prošly až po opakování. Růst první hodnoty směřuje pozornost k runneru; růst druhé může upozornit na test, aplikaci nebo společná data a vyžaduje samostatnou diagnostiku.

Co tím získáte

Vyhrazený runner a zdokumentovaná relace mění lokální skript v opakovatelnou kontrolu konkrétního buildu. Tým ví, které selhání patří aplikaci, testu nebo infrastruktuře, a má podklady pro jeho zopakování. Zároveň může build a rychlé testy ponechat na hostovaných runnerech a citlivější desktopovou vrstvu provozovat v kontrolovaném rozsahu.

Další krok

Vyberte jeden kritický WPF nebo WinForms scénář a spusťte ho desetkrát na budoucím runneru bez vzdálených zásahů. Zaznamenejte relaci, účet, verze, data a diagnostiku. Teprve když pilot spolehlivě odliší chybu prostředí od chyby produktu, přidejte blokování releasu a rozšiřujte sadu.