(@ Dario: accetto la sfida!!! )
Nel mio ultimo post ho annunciato il rilascio di un framework per effettuare test funzionali per applicazioni desktop in maniera del tutto automatica. Dario ha accettato la mia richiesta rispondendo con un bel post su TestApi e Input Injection. Tutto ciò mi ha messo voglia di provare a rifare il solito test da lui proposto, però utilizzando white, così possiamo confrontare i due framework. Cominciamo!!
Prima di tutto lo screenshot della mia applicazione, non è proprio identica a quella di Dario, ma va benissimo!
Come sappiamo, lo scopo del test è quello di:
- Lanciare l'applicazione
- Selezione della modalità di filtraggio (ovvero selezione di un item della ComboBox)
- Inserimento della filterExpression (typing nella TextBox)
- Click del Button di ricerca
- Valutazione dei risultati nella ListBox
Niente di più facile!! Come per le TestApi, per prima cosa nello XAML dobbiamo impostare per ogni elemento interessato l’Attached Properties AutomationProperties.AutomationId, successivamente aggiungiamo un progetto di tipo Class Library per i test. Aggiungiamo come reference al progetto le librerie Core.dll, White.NUnit.dll e nunit.framework.dll, quest’ultima libreria viene fornita insieme ai binari di white però in realtà fa parte del framework NUnit. Adesso non ci resta che aggiungere una nuava classe e scrivere il metodo di test come mostrato nel seguente snippet:
1: [TestFixture]
2: public class MainWindowTests
3: {
4: private const string path = @"C:\…\WhiteDemoWithWpf.exe";
5:
6: [Test]
7: public void When_click_search_should_filter_loaded_data_by_selected_mode_and_typed_expression()
8: {
9: string productNameToMatch = "Chang";
10:
11: //Esecuzione dell'applicazione
12: var application = Application.Launch(path);
13:
14: //Ottengo la Window e verifico che non sia Null
15: var window = application.GetWindow("MainWindow", InitializeOption.NoCache);
16: Assert.That(window,Is.Not.Null);
17:
18: //Seleziono un elemento della ComboBox
19: var lstFilterCriteria = window.Get<ComboBox>("lstFilterCriteria");
20: lstFilterCriteria.Select(3);
21:
22: //Scrivo il Product Name per il test
23: var txtProductName = window.Get<TextBox>("txtProductName");
24: txtProductName.Text = productNameToMatch;
25:
26: //Clicco il Button per effettuare la ricerca
27: var btnFilterProducts = window.Get<Button>("btnFilterProducts");
28: btnFilterProducts.Click();
29:
30: //Verifico che il numero totale di elementi della lista sia 1
31: var listViewProducts = window.Get<ListView>("listViewProducts");
32: Assert.That(listViewProducts.Rows.Count, Is.EqualTo(1));
33:
34: //Verifico il contenuto della cella contenente
35: //il risultato della ricerca con il Product Name per il test
36: var cell = listViewProducts.Rows[0].Cells[0];
37: Assert.That(cell.Text, Is.EqualTo(productNameToMatch));
38:
39: //Chiudo l'applicazione
40: application.Kill();
41: }
42: }
I commenti descrivono chiaramente la logica del metodo. Lanciamo il test (sempre con le mani dietro alla testa ) e godiamoci il risultato:
Le prime tre righe sono “problemi” di confgurazione non essenziali per questa demo.
Confrontando il solito metodo di test scritto con i due framework devo dire che white al momento offre un modello di pilotaggio della UI molto più ricco e semplice da utilizzare. Atro aspetto interessante è che white permette di testare anche applicazioni Java scritte in SWT!!
Devo ammettere che vedere l’applicazione vivere di vita propria fa un certo effetto!!!