UI testing in applicazioni .NET desktop e mobile
Qualsiasi sia il software che stiamo sviluppando, abbiamo una certezza: prima di fare un deploy sull’ambiente di produzione delle ultime modifiche, un rilascio sullo store o ai nostri customer, dovremo fare un accurato giro di test per assicurarci che tutto funzioni correttamente. I test, purtroppo, vengono spesso ignorati poiché non sono considerati parte fondamentale del business degli applicativi, almeno nelle prime fasi di vita di un progetto. Con l’avvento di pratiche di DevOps, come abbiamo visto in articoli dedicati, il ciclo di vita del software è stato completamente rivoluzionato e, considerando che le tempistiche di rilascio tra una versione e la successiva sono sempre minori, se non tendenti a zero, diventa sempre più complesso prevedere delle fasi di test manuali come siamo stati abituati a fare in passato.
I test non solo sono importanti nelle prime fasi di sviluppo del software, ma diventano via via più importanti anche nelle fasi post-deployment poiché, magari, vogliamo monitorare che l’infrastruttura sia configurata correttamente, che le API rispondano correttamente, piuttosto che l’interfaccia grafica si comporti correttamente come ci aspettiamo. E’ fondamentale che, al crescere della complessità delle applicazioni, cresca anche il numero di test e che la maggior parte di questi siano automatizzati/automatizzabili, per ridurre gli effort spesi in testing manuali e per aumentare l’affidabilità dei test stessi.
Mike Cohn, uno dei collaboratori al metodo di sviluppo Scrum e autore del libro Succeeding with Agile, ha introdotto, per i progetti e i team di sviluppo che vogliono intraprendere in maniera seria lo sviluppo e il mantenimento dei test: la piramide dei test.
Questa piramide comprendeva originariamente solamente tre livelli, ovvero unit test, service test e UI test, ma è stata modificata nella sua complessità nel corso degli anni per via di nuove pratiche introdotte sia a livello di metodologia, che di sviluppo software (pensiamo, ad esempio, ai micro-service). Nonostante la sua semplicità, la piramide introdotta da Mike Cohn ci offre diversi insegnamenti:
- Ogni test ha una precisa area di funzionamento e un proprio scopo, in base al livello in cui si trova: unit test, ad esempio, possono testare una unità minima del prodotto, mentre in un test sulla GUI, ad esempio, con la sola pressione di un pulsante, potremo invocare diverse sequenze di codice;
- Ad un livello più alto, corrisponde maggior complessità nello scrivere e nel mantenere i test stessi, proprio per via delle numerose componenti che possono essere coinvolte;
- Al crescere delle aree coinvolte i test saranno più lenti, poiché è richiesta maggior complessità per avere in piedi l’infrastruttura necessaria alla loro esecuzione.
Dovendo scrivere, quindi, una suite di test case da zero, sarebbe bene iniziare a scrivere molti unit test poiché sono più semplici, possono farli direttamente gli sviluppatori che hanno costruito la business logic, sono veloci da eseguire anche se creati a migliaia e ci garantiscono un’alta coverage del progetto, assicurandoci di conseguenza che tutto l’applicativo che stiamo sviluppando funzioni.
Tuttavia, ci sono diversi scenari che non possono essere testati con unit test o con dati finti e questo è il caso dei test dei componenti e l’interazione tra di essi, come può verificarsi spesso nel mondo desktop o mobile: immaginiamo il click su un pulsante che effettua una validazione, in cui vogliamo assicurarci che venga mostrato un eventuale messaggio di errore se i campi non sono stati compilati correttamente, piuttosto che la navigazione alla pagina di acquisto ci rimandi alla pagina corretta in cui possiamo vedere i dettagli del carrello con i prodotti pronti per essere acquistati e così via. Tutti questi scenari, che non coinvolgono una parte di backend, almeno in maniera diretta, possono essere verificati tramite UI test.
Gli UI test sono particolari tipi di test che servono, per l’appunto, a determinare che l’interfaccia grafica dell’applicazione funzioni correttamente a valle di input dell’utente, piuttosto che di trigger invocati automaticamente dopo cambi di stato a livello applicativo. Non solo, anche il layout e l’usabilità dello stesso devono essere coerenti in tutta l’applicazione e, magari, verificati tramite policy condivise a livello aziendale. Nella piramide di Mike Cohn, sono considerati allo stesso livello degli end-to-end test.
Applicare test all’interfaccia grafica può sembrare inizialmente complesso ma, sostanzialmente, si tratta di scrivere codice aggiuntivo per fare inizializzazione di componenti della UI, di inserire dati in caselle di testo, premere pulsanti e osservare il comportamento. All’atto pratico, l’uso di SDK o di strumenti qualificati come Selenium, basato su REST API, ci possono aiutare nello standardizzare la scrittura dei test e trattarli come se fossero normali unit test che, magari, siamo più abituati a scrivere.
La parte complessa rimane verificare il layout come, ad esempio, la verifica dei margini, colori e così via: purtroppo, ad oggi, non ci sono grandi strumenti per determinare eventuali errori, se non quelli più banali e, proprio per questo motivo, come vedremo nelle prossime pagine, avremo accesso agli screenshot che ci permetteranno anche di fare analisi storiche e comparative in modo manuale per determinare eventuali errori nell’esecuzione dei test.
Scrivere UI test è una procedura delicata, che richiede attenzione e configurazioni particolari in base alle piattaforme che stiamo utilizzando: sia che facciamo riferimento al mobile, piuttosto che al mondo desktop, in questo caso, abbiamo .NET come baseline per introdurre i concetti base legati agli UI test e, nelle prossime pagine, cercheremo di capire come gli strumenti che Microsoft ci mette a disposizione possano venirci in aiuto per aumentare la coverage delle nostre applicazioni con semplicità.
Contenuti dell'articolo
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Definire stili a livello di libreria in Angular
Popolare una classe a partire dal testo, con Semantic Kernel e ASP.NET Core Web API
Ottimizzare le performance delle collection con le classi FrozenSet e FrozenDictionary
Eseguire una ricerca avanzata per recuperare le issue di GitHub
Registrare servizi multipli tramite chiavi in ASP.NET Core 8
Testare l'invio dei messaggi con Event Hubs Data Explorer
Migliorare la sicurezza dei prompt con Azure AI Studio
Utilizzare Tailwind CSS all'interno di React: installazione
Come EF 8 ha ottimizzato le query che usano il metodo Contains
Creare gruppi di client per Event Grid MQTT
Disabilitare automaticamente un workflow di GitHub (parte 2)
Rinnovare il token di una GitHub App durante l'esecuzione di un workflow
Sommario
Top Ten Articoli
- Realizzare una Progressive Web Application con Blazor e ASP.NET Core
di Giampaolo Tucci - Gestire le chiamate a servizi esterni in ASP.NET Core e Blazor tramite Polly
di Morgan Pizzini - Usare gRPC come infrastruttura per i nostri servizi web
di Morgan Pizzini - Abilitare e gestire il prerendering nelle applicazioni Blazor WebAssembly
di Marco De Sanctis - Creare API GraphQL con ASP.NET Core e HotChocolate
di Moreno Gentili - Le novità di Blazor in .NET 6.0
di Morgan Pizzini - Blazor e il pattern Model-View-ViewModel
di Giampaolo Tucci - Le novità in ASP.NET Core e Blazor con .NET 7
di Morgan Pizzini - Introduzione a Blazor WebAssembly
di Marco De Sanctis, Moreno Gentili - Le novità di ASP.NET Core 5
di Marco De Sanctis
Articoli via e-mail
Iscriviti alla nostra newsletter nuoviarticoli per ricevere via e-mail le notifiche!
In primo piano
I più letti di oggi
- Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
- ecco tutte le novità pubblicate sui nostri siti questa settimana: https://aspit.co/wkly buon week-end!
- Utilizzare il metodo CountBy di LINQ per semplificare raggruppamenti e i conteggi
- Creare una libreria CSS universale: Cards
- Eseguire script pre e post esecuzione di un workflow di GitHub
In evidenza
- Il meglio della settimana
- Utilizzare il metodo CountBy di LINQ per semplificare raggruppamenti e i conteggi
- Eseguire script pre e post esecuzione di un workflow di GitHub
- Creare una libreria CSS universale: Cards
- Migliorare l'organizzazione delle risorse con Azure Policy
- Effettuare il log delle chiamate a function di GPT in ASP.NET Web API
- Leggere la posta usando il protocollo IMAP tramite la libreria MailKit
- Eseguire una ricerca avanzata per recuperare le issue di GitHub