Sono un grande fan del Principio di Pareto (o legge “80/20”) e mi piace applicarlo nella strategia per il testing di un progetto.
Dalla mia esperienza è molto difficile aver un buon code coverage (> 60%) tramite unit-test se non tutti i membri del team (e anche tech/team lead, architetti e business) ne vedono i benefici.
Un approccio che ho trovato più semplice da realizzare è fare un mix di unit tests, integration tests e UI tests. Degli integration tests lato backend/E2E ne ho gia parlato in un precedente articolo. Dal mio punto di vista, dei semplici test automatizzati sull’interfaccia, permettono di coprire alcune parti mancanti dai unit test e E2E test.
Secondo me è buona pratica avere almeno alcuni test di base, per essere sicuri che l’integrazione tra le parti funzione correttamente, ed evitare test manuali ripetitivi, e i tester possono dedicarsi a qualche test piu stimolante! Se realizzati senza esagerare nel testare i piccoli dettagli, possono esssere un buon investimento: non commettete l’errore di utilizzare gli UI test per sostituire gli Unit tests (e ovviamente viceversa). Ogni strumento rende al massimo se utilizzato correttamente e con il giusto scopo.
Avendo avuto una buona esperienza con Browserstack (www.browserstack.com) per automatizzare il test su una applicazione web SPA in Angular, cercavo qualcosa di simile per automatizzare dei test di User Interface su un client WPF. Attualmente, oltre a questo client, altri team avrebbero anche la necessità di testare delle applicazioni client/server legacy scritte in Delphi e C#.
Ho trovato quindi questo interessante articolo su WinAppDriver (WAD) e realizzato un PoC partendo dagli esempi presenti sul repository GitHub. Gli esempi dimostrano come effettuare i test automatizzati su applicazioni WPF, Windows Forms e Windows App. Devo dire che Microsoft ha fatto veramente un bel lavoro, e grazie alla mia precedente esperienza con Selenium Drivers e le API di Selenium utilizzate con BrowserStack, in poche ore il tutto – per mia grande soddisfazione – funzionava perfettamente!
Le uniche limitazioni sono che:
- richiede Windows 10,
- bisogna installare il pacchetto sulla macchina in cui si eseguono i test e
- bisogna abilitare il DevelopmentMode.
Per identificare gli ID degli elementi da testare/utilizzare, si puo utilizzare il tool “Inspect” fornito dal Windows 10 SDK.
Aggiornamento 2019: ora è anche disponibile un nuovo tool chiamato “WinAppDriver UIRecorder” disponibile nello stesso repository, che semplifica la scrittura del codice e dell’identificazione degli xpath da utilizzare. Uno strumento veramente utile!
Devo dire che non è stato semplice, perchè il client non è proprio convenzionale, in quanto all’avvio integra un browser che permette di fare l’autenticazione OAuth2. In pratica il loader WPF si comportava come uno splash screen, e quindi invalidava il puntatore alla finestra e i lookup degli ID dei controlli fallivano. Per fortuna un caso simile era gia stato risolto, e il tutto documentato sul repository in GitHub.
Un’altra caratteristica è che permette di agganciarsi a runtime ad una applicazione in esecuzione ed eseguire l’automazione. Molto utile nei casi in cui si abbiano dipendenze di terze parti che non possono essere automatizzate, oppure per motivi di performance.
