Test E2E: Un tutorial e una guida architettonica
I test end-to-end (E2E) aiutano a convalidare i flussi più importanti della tua applicazione, come le richieste di login degli utenti. Per lo sviluppo front-end, i test E2E aiutano a verificare se l’interfaccia utente corretta è stata presentata. Per lo sviluppo back-end, i test E2E aiutano a verificare se un flusso importante nei vostri servizi di back-end restituisce l’output previsto.
Questo post vi introdurrà ai test E2E e vi darà consigli utili. Spiegheremo anche come scrivere test riutilizzabili in modo che possano essere usati per creare test E2E più facilmente. Come forse saprete, i test E2E sono spesso una grande frustrazione per gli sviluppatori in quanto richiedono molto sforzo per scrivere, eseguire e mantenere.
Prima di tutto, diamo un’occhiata a dove si trova il test E2E nella piramide del test del software.
Posizione dei test E2E nella piramide dei test
Guardando la piramide dei test, troviamo quattro tipi principali di test che ci aiutano a garantire la qualità del codice:
- I test E2E aiutano a verificare i percorsi ad alto valore nella tua applicazione. In altre parole, aiutano a verificare le storie degli utenti poiché spesso rappresentano i flussi nella vostra applicazione.
- I test di integrazione aiutano a verificare l’integrazione di più funzioni o componenti. I test di integrazione possono dirvi se il vostro codice funziona in modo coerente con altre funzioni.
- I test di unità aiutano a verificare la logica di business delle funzioni. I test unitari sono la forma più basilare di test, e assicurano che la logica di business sia corretta.
- Infine, non possiamo dimenticare l’analisi statica o test statico. I test statici aiutano a trovare errori di battitura o di tipo.
Secondo questa piramide, la maggior parte dei test dovrebbero essere test unitari, con meno test di integrazione e ancora meno test E2E. Tuttavia, è ancora importante verificare i flussi nella vostra applicazione. I test E2E sono difficili da mantenere e richiedono molto sforzo. Quindi, verificate solo i flussi più importanti con i test E2E. Altri tipi di test come quelli di integrazione e di unità dovrebbero già darvi sufficiente fiducia nel vostro codice.
Diverse strategie di test E2E
Lasciatemi dire che esistono diverse strategie. Possiamo scegliere tra test E2E orizzontale e test E2E verticale. Entrambe le strategie valgono la pena di essere esplorate perché permettono di testare diversi scenari. Impariamo cosa fa ogni strategia.
Strategia #1: Vertical End-to-End Testing
Questa strategia si concentra sul testare tutti i livelli della piramide del testing. Include test di unità, test di integrazione e test UI. Il tuo obiettivo è quello di testare un componente ad un livello granulare usando i test unitari, testare come un componente si comporta quando interagisce con altri componenti usando i test di integrazione, e infine, verificare il comportamento del componente quando gli utenti interagiscono attraverso l’UI.
Più comunemente, si vuole usare una pipeline di integrazione continua per automatizzare questi test per ogni commit di codice o richiesta di pull.
Strategia #2: Horizontal End-to-End Testing
I test orizzontali E2E si concentrano sulla verifica di un flusso utente completo. Ecco un esempio di flusso per un webshop:
- Apri la pagina del prodotto
- Seleziona la taglia del prodotto
- Aggiungi il prodotto al carrello
- Vai alla cassa
- Compila l’indirizzo e le informazioni di pagamento
- Completa il pagamento
- Mostra la schermata di conferma dello shopping
Qui vogliamo verificare ogni transazione del flusso utente. Spesso, questo tipo di test verifica l’interazione tra diverse applicazioni e verifica i cambiamenti di stato per quelle applicazioni.
Nota che questi tipi di test sono costosi da scrivere. Richiede un po’ di tempo per definire i flussi utente e scrivere questi test. Pertanto, cercate di concentrarvi sui percorsi di transazione critici per la vostra applicazione.
Tuttavia, assicuratevi di testare questi flussi utente critici per diverse condizioni. Questa strategia vi permette di ottenere un’immagine completa della robustezza del flusso utente. Queste condizioni includono:
- Scenari temporali complessi: Per esempio, un biglietto di un concerto è disponibile solo per 15 minuti.
- Inserimento di dati diversi o dati mancanti.
- Interruzioni del flusso: Un utente decide di lasciare la pagina di checkout per visualizzare un’altra pagina di prodotto. Per esempio, dobbiamo verificare se il componente salva lo stato di checkout.
Prossimo, impariamo quando scrivere test E2E.
Quando scrivere test E2E
Potreste non sapere che i test E2E sono test costosi da eseguire nella vostra pipeline di integrazione continua. Spesso richiedono molta preparazione, come la creazione di un database che imita i dati di produzione. Inoltre, a volte rappresentano flussi che richiedono tempo nella vostra applicazione. Pertanto, possono essere lenti e richiedere più risorse per essere eseguiti.
Utilizza i test E2E per verificare i flussi più importanti nella tua applicazione. Esempi di flussi ad alto valore includono:
- Login e logout
- Registrazione di un nuovo utente
- Aggiungi un articolo al carrello
- Modifica la tua password
- Qualsiasi altro flusso importante relativo al tuo servizio
Tuttavia, non dimenticare di verificare la logica di business che scrivi con test di unità e integrazione. La combinazione di test unitari e di integrazione dovrebbe darvi molta fiducia sulla qualità del vostro codice. I test E2E ti aiutano ad aumentare questa fiducia per i percorsi critici.
Ecco alcuni consigli utili per scrivere test E2E.
Suggerimenti per scrivere test E2E
Focus on Writing Reusable Tests
Il primo e più importante consiglio è di scrivere test e componenti piccoli, indipendenti e riutilizzabili. Questo ti permette di mettere insieme più componenti di piccole dimensioni per creare flussi utente completi end-to-end più facilmente. Invece di scrivere molti componenti personalizzati solo per essere usati dai test E2E, concentrati sulla scrittura di componenti riutilizzabili.
Scrivere componenti piccoli e indipendenti aiuta il riutilizzo del codice e riduce il tempo di risoluzione degli errori. Inoltre, è più facile aggiornare i piccoli componenti quando cambiano le funzionalità o i flussi utente.
Considera sempre il motivo per scrivere un test E2E
Quando vuoi coprire un particolare flusso con un test E2E, considera se vale la pena coprirlo. Testare solo flussi di utenti di alto valore con test E2E. Per esempio, non si dovrebbe testare se viene mostrato un messaggio di errore quando un utente inserisce un indirizzo email errato. Questo è un caso d’uso troppo semplice che non si adatta a un test E2E. Questo requisito può essere semplicemente testato con un test unitario.
D’altra parte, vale la pena testare se la pagina di login reindirizza l’utente alla giusta pagina dell’applicazione dopo aver effettuato con successo il login. Questo è un flusso prezioso per i vostri utenti per poter utilizzare l’applicazione. In breve, considera sempre la ragione per scrivere un test E2E.
I test E2E non dovrebbero dipendere dai dettagli di implementazione
Non vuoi aggiornare i test E2E ogni volta che cambi i dettagli di implementazione di un certo flusso. Pertanto, si vuole scrivere componenti che permettano di astrarre i dettagli dell’implementazione. I test E2E diventano molto più facili da mantenere, e più divertenti da scrivere, quando i dettagli di implementazione sono nascosti nei componenti. In breve, i test E2E dovrebbero essere indipendenti dai dettagli dell’implementazione.
Prossimo, guardiamo le insidie dei test E2E.
Pitfalls of E2E Testing
Ecco una lista di insidie comuni associate ai test E2E:
- I test E2E non dovrebbero provare a testare il più possibile in un colpo solo. Spesso gli sviluppatori scrivono enormi test E2E che verificano ogni aspetto del flusso utente. Mantenete le cose semplici e verificate gli aspetti più importanti del vostro flusso utente. Per esempio, per un flusso di login, devi solo verificare se l’utente viene reindirizzato alla pagina dell’applicazione. Questo renderà più facile per gli sviluppatori mantenere e aggiornare i test E2E.
- Quando un test E2E fallisce, può essere difficile trovare la causa esatta del fallimento. Tuttavia, è possibile ridurre gli sforzi di debug necessari coprendo la logica di business con test unitari e di integrazione. Alcuni strumenti forniscono anche una buona analisi delle cause alla radice, compresi screenshot e log della console dei passi di test falliti, che possono ridurre il tempo di risoluzione dei problemi.
- I test E2E richiedono una quantità considerevole di tempo nella vostra pipeline di integrazione continua (CI). Possono bloccare la vostra pipeline CI, il che rallenta lo sviluppo complessivo. Questo significa che potresti aver bisogno di investire nella tua pipeline CI per avere qualche pipeline in più per eseguire i test.
- I test E2E sono uno sforzo continuo. Ogni volta che viene aggiunta una nuova funzionalità o una vecchia funzionalità cambia, è probabile che tu debba aggiornare i tuoi test E2E. Tuttavia, possiamo ridurre questo sforzo scrivendo componenti riutilizzabili che astraggono i dettagli dell’implementazione. Inoltre, alcuni strumenti usano l’intelligenza artificiale per aiutare ad adattare i test quando il codice cambia, riducendo la manutenzione dei test.
Ora, diamo un breve sguardo alle differenze tra test di sistema e test E2E.
Test di sistema vs. test E2E – Qual è la differenza?
Quindi, qual è la differenza tra test di sistema e test E2E? Il test di sistema si concentra sulla convalida dei requisiti funzionali e non funzionali. Spesso, è completato da un team esterno che tratta l’applicazione come una scatola nera. In altre parole, non sanno nulla del funzionamento dell’applicazione eccetto i requisiti che dovrebbe soddisfare.
Tuttavia, questa forma di test viene spesso confusa con il test E2E in quanto il test di sistema è una forma di test E2E. Tuttavia, i test di sistema verificano molto di più dei test E2E. Per esempio, il test di sistema misura la scalabilità, le prestazioni o l’affidabilità. Mentre i test E2E si concentrano sul corretto completamento dei flussi utente.
Infine, riassumiamo gli insegnamenti di questo articolo.
Conclusione su E2E
I test end-to-end sono piuttosto potenti in quanto aiutano a convalidare i flussi utente di alto valore o le storie utente. Aiutano a garantire la qualità della vostra applicazione.
Tuttavia, scrivere e mantenere i test E2E può richiedere tempo e sforzi significativi. È possibile ridurre questo sforzo scrivendo piccoli componenti riutilizzabili che astraggono i dettagli dell’implementazione. Alcuni strumenti aiutano anche a creare test più resistenti utilizzando AI o più attributi per identificare ogni elemento. Quindi, non è necessario aggiornare i test E2E ogni volta che i dettagli di implementazione cambiano per i flussi utente di alto valore. Inoltre, i componenti riutilizzabili permettono di mettere in fila quei componenti per creare facilmente flussi di test E2E.
I test E2E dovrebbero coprire i flussi più importanti della vostra applicazione. Testano i flussi che i vostri utenti e clienti seguono per ottenere valore dalla vostra applicazione. Se non possono accedere o aggiungere un articolo al carrello, se ne andranno (se possono) o chiameranno il supporto se sono costretti a usare la vostra applicazione. Per esempio, volete coprire il flusso di login e logout, ma siete meno interessati a verificare un messaggio di errore dopo aver inserito un cattivo indirizzo email.
Alla fine, i test E2E dovrebbero essere divertenti da scrivere. Non dovrebbero richiedere molto tempo e sforzo per scrivere e mantenere. Mantenete i test E2E semplici e concentratevi su componenti riutilizzabili, e vedrete grandi risultati!
Questo post è stato scritto da Michiel Mulders. Michiel è un appassionato sviluppatore di blockchain che ama scrivere contenuti tecnici. Oltre a questo, ama imparare il marketing, la psicologia UX e l’imprenditoria. Quando non sta scrivendo, probabilmente si sta godendo una birra belga!