Scopri come combinare diversi tipi di test in una strategia ragionevole che si adatti al tuo progetto.
Siamo felici di rivederti. L'ultimo articolo ha gettato le basi su come approcciare i diversi tipi di test e cosa contengono, oltre a chiarire le definizioni dei tipi di test. Ricordi questa immagine meme? Forse ti starai chiedendo come possono funzionare insieme tutti i tipi di test che hai imparato a conoscere.
A seguire, imparerai proprio questo. Questo articolo fornisce un'introduzione su come combinare questi tipi di test in strategie ragionevoli e scegliere quella più adatta al tuo progetto.
Puoi confrontare le strategie con una serie di forme per comprenderne meglio il significato. Ecco un elenco di strategie con le rispettive dimensioni e gli ambiti di sviluppo.
Diamo un'occhiata più da vicino alle strategie e scopriamo il significato dei loro nomi.
Determina gli obiettivi dei test: che cosa vuoi ottenere con questi test?
Prima di iniziare a creare una buona strategia, stabilisci l'obiettivo del test. Quando ritieni che la tua applicazione sia stata testata a sufficienza?
Il raggiungimento di un'elevata copertura dei test è spesso considerato l'obiettivo finale degli sviluppatori quando si tratta di test. Ma è sempre l'approccio migliore? Potrebbe esserci un altro fattore critico da considerare quando si decide una strategia di test: soddisfare le esigenze degli utenti.
In qualità di sviluppatore, utilizzi anche molte altre applicazioni e dispositivi. In questo senso, sei l'utente che si affida a tutti questi sistemi per "funzionare". A tua volta, ti affidi a innumerevoli sviluppatori che fanno del loro meglio per far funzionare le loro applicazioni e i loro dispositivi. In qualità di sviluppatore, anche tu ti impegni a essere all'altezza di questa fiducia. Quindi, il tuo primo obiettivo dovrebbe essere sempre quello di distribuire software funzionante e servire i tuoi utenti. Questo vale anche per i test che scrivi per garantire la qualità dell'applicazione. Kent C. Dodds lo riassume molto bene nel suo post Static vs Unit vs Integration vs E2E Testing for Frontend Apps:
Più i test assomigliano al modo in cui viene utilizzato il software, maggiore è la sicurezza che possono darti.
di Kent C. Dodds
Kent lo descrive come un modo per acquisire fiducia nei test. Più ti avvicini agli utenti scegliendo un tipo di test adatto, più puoi avere la certezza che i risultati dei test siano validi. In altre parole, più sali nella piramide, più acquisisci sicurezza. Ma aspetta, cos'è la piramide?
Determinazione delle strategie di test: come scegliere una strategia di test
Come primo passaggio, determina quali parti dei requisiti devi controllare per assicurarti che siano soddisfatti. Scopri quali tipi di test utilizzare e con quale livello di dettaglio puoi ottenere la massima affidabilità mantenendo una struttura dei costi efficiente. Molti sviluppatori affrontano questo argomento utilizzando analogie. Ecco i più comuni, a partire dal classico più noto.
Il classico: la piramide dei test
Non appena inizi a cercare strategie di test, probabilmente ti imbatterai nella piramide dell'automazione dei test come prima analogia. Mike Cohn ha introdotto questo concetto nel suo libro "Succeeding with Agile". In seguito, Martin Fowler ha ampliato il concetto nel suo articolo The Practical Test Pyramid. Puoi rappresentare visivamente la piramide come segue:
Come mostrato in questo disegno, la piramide di test è composta da tre livelli:
Unità. Questi test si trovano al livello di base della piramide perché sono rapidi da eseguire e semplici da gestire. Sono isolati e hanno come target le unità di test più piccole. Ad esempio, vedi un tipico test delle unità per un prodotto molto piccolo.
Integrazione. Questi test si trovano al centro della piramide, perché hanno una velocità di esecuzione accettabile, ma ti avvicinano all'utente più di quanto possano fare i test delle unità. Un esempio di test di integrazione è un test API. Puoi anche classificare i test dei componenti come questo tipo.
Test E2E (chiamati anche test UI). Questi test simulano un utente reale e la sua interazione. Questi test richiedono più tempo per l'esecuzione e sono quindi più costosi. Si trovano in cima alla piramide.
Confidenza e risorse
Come accennato in precedenza, l'ordine dei livelli non è casuale. Mostrano le priorità e i costi corrispondenti. In questo modo avrai un'idea chiara di quanti test dovresti scrivere per ogni livello. Hai già visto questo aspetto nella definizione dei tipi di test.
Poiché i test E2E sono i più vicini ai tuoi utenti, ti danno la massima certezza che la tua applicazione funzioni come previsto. Tuttavia, richiedono uno stack di applicazioni completo e un utente simulato, pertanto sono anche potenzialmente i più costosi. Pertanto, l'affidabilità è in concorrenza diretta con le risorse necessarie per eseguire i test.
La piramide cerca di risolvere questo problema facendoti concentrare maggiormente sui test di unità e dando rigorosamente la priorità ai casi coperti dai test E2E. Ad esempio, i percorsi degli utenti più importanti o i punti più vulnerabili ai difetti. Come sottolinea Martin Fowler, i due punti più essenziali della piramide di Cohn sono i seguenti:
- Scrivi test con granularità diverse.
- Più alto è il livello, minore è il numero di test da eseguire.
Pyramid si è evoluto! Adattamenti delle piramidi di test
Da diversi anni, le discussioni ruotano attorno alla piramide. La piramide sembra semplificare eccessivamente le strategie di test, tralascia molti tipi di test e non si adatta più a tutti i progetti reali. Pertanto, potrebbe essere fuorviante. La piramide ha perso la sua forma? Guillermo Rauch ha un'opinione in merito:
Scrivi i test. Non troppi. Principalmente integrazione.
di Guillermo Rauch
È una delle citazioni più comuni su questo argomento, quindi analizziamola:
- "Scrivi test". Non solo perché crea fiducia, ma anche perché fa risparmiare tempo nella manutenzione.
- "Non troppi". Una copertura del 100% non è sempre un bene, perché i test non vengono classificati in ordine di priorità e la manutenzione sarà elevata.
- "Mostly integration". Anche in questo caso, l'accento è posto sui test di integrazione: hanno il valore aziendale più elevato, in quanto offrono un livello di confidenza elevato ogni giorno, mantenendo al contempo un tempo di esecuzione ragionevole.
Questo ti fa riflettere di nuovo sulla piramide dei test e spostare l'attenzione sui test di integrazione. Negli ultimi anni sono stati proposti molti adattamenti, quindi diamo un'occhiata a quelli più comuni.
Diamante di test
Il primo adattamento rimuove l'enfasi eccessiva sui test delle unità, come mostrato nella piramide dei test. Immagina di aver raggiunto una copertura del 100% nei test delle unità. Tuttavia, la prossima volta che rifattorizzerai, dovrai aggiornare molti di questi test delle unità e potresti avere la tentazione di saltarli. Quindi si erodono.
Di conseguenza, e insieme alla maggiore attenzione ai test di integrazione, potrebbe emergere la seguente forma:
Una piramide si evolve in un diamante. Puoi vedere i tre strati precedenti, ma con una dimensione diversa, e lo strato di unità è stato tagliato:
- Unità. Scrivi i test delle unità come li hai definiti in precedenza. Tuttavia, poiché tendono a erodersi, dai la priorità e copri solo i casi più critici.
- Integrazione. I test di integrazione che conosci, che testano la combinazione di singole unità.
- E2E. Questo livello gestisce i test della UI in modo simile alla piramide dei test. Assicurati di scrivere test E2E solo per gli scenari di test più critici.
Testiamo il favo
Esiste un altro adattamento, introdotto da Spotify, simile al diamante di test, ma ulteriormente specializzato per i sistemi software basati su microservizi. Il nido d'ape di test è un'altra analogia visiva per la granularità, l'ambito e il numero di test da scrivere per un sistema software basato su microservizi. A causa delle loro dimensioni ridotte, la complessità più significativa di un microservizio non risiede nel servizio stesso, ma nel modo in cui interagisce con gli altri. Pertanto, una strategia di test per un microservizio dovrebbe concentrarsi principalmente sui test di integrazione.
Questa forma ricorda un nido d'ape, da cui il nome. Ha i seguenti livelli:
- Test integrati. L'articolo di Spotify utilizza una citazione di J. B. Rainsberger per definire questo livello: "Un test che verrà superato o meno in base alla correttezza di un altro sistema". Questi test hanno dipendenze esterne che devi considerare e, al contrario, il tuo sistema potrebbe essere una dipendenza che interrompe altri sistemi. Come per i test E2E in altre analogie, utilizza questi test con attenzione, solo per i casi più essenziali.
- Test di integrazione. Come per altri adattamenti, dovresti concentrarti su questo livello. Contiene test che verificano la correttezza del servizio in modo più isolato, ma comunque in combinazione con altri servizi. Ciò significa che i test includeranno anche altri sistemi e si concentreranno sui punti di interazione, ad esempio tramite test delle API.
- Test sui dettagli di implementazione. Questi test assomigliano ai test delle unità, ovvero test che si concentrano su parti del codice che sono naturalmente isolate e quindi hanno una propria complessità interna.
Se vuoi saperne di più su questa strategia di test, consulta il post che confronta la piramide di test con il nido d'ape di Martin Fowler e l'articolo originale di Spotify.
Trofeo di test
Puoi già notare un'attenzione ripetuta ai test di integrazione. Tuttavia, un altro tipo di test che hai incontrato nell'articolo precedente non è un test in teoria, ma è comunque un aspetto importante da considerare in una strategia di test. L'analisi statica non è presente nella piramide dei test e nella maggior parte degli adattamenti che hai visto finora. Esiste l'adattamento del trofeo di test che tiene conto dell'analisi statica, mantenendo l'attenzione sui test di integrazione. Il trofeo dei test è nato dalla citazione precedente di Guillermo Rauch ed è stato sviluppato da Kent C. Dodds:
Il trofeo dei test è un'analogia che descrive la granularità dei test in un modo leggermente diverso. È composta da quattro livelli:
- Analisi statica. Svolge un ruolo fondamentale in questa analogia e ti consente di individuare errori di battitura, errori di stile e altri bug semplicemente eseguendo i passaggi di debug già descritti.
- Test delle unità. Garantiscono che l'unità più piccola venga testata in modo appropriato, ma il trofeo dei test non li enfatizzerà nella stessa misura della piramide dei test.
- Integrazione. Questo è l'aspetto principale, in quanto bilancia il costo e la maggiore affidabilità nel modo migliore, come con altri adattamenti.
- Test della UI. Includendo i test E2E e visivi, si trovano in cima al trofeo dei test, in modo simile al loro ruolo nella piramide dei test.
Per saperne di più sul trofeo dei test, consulta il blog post di Kent C. Dodds su questo argomento.
Alcuni approcci più incentrati sulla UI
Tutto questo è molto bello, ma non importa come chiami la tua strategia, "piramide", "nido d'ape" o "diamante", manca ancora qualcosa. Sebbene l'automazione dei test sia preziosa, è importante ricordare che i test manuali sono comunque essenziali. I test automatici dovrebbero alleggerire le attività di routine e consentire ai tecnici di garanzia di qualità di concentrarsi sulle aree cruciali. Anziché sostituire i test manuali, l'automazione dovrebbe integrarli. Esiste un modo per integrare i test manuali con l'automazione per ottenere risultati ottimali?
Test cono gelato e test granchio
Esistono infatti due adattamenti della piramide di test che si concentrano maggiormente su questi metodi di test incentrati sulla UI. Entrambi offrono il vantaggio di un'elevata affidabilità, ma sono naturalmente più costosi a causa della maggiore lentezza nell'esecuzione dei test.
Il primo, il cono di ghiaccio di prova, sembra una piramide al contrario. Senza il passaggio di test manuale, è anche nota come pizza di test.
Il cono di gelato si concentra maggiormente sui test manuali o dell'interfaccia utente e meno sui test delle unità. Spesso si manifesta in progetti in cui gli sviluppatori hanno iniziato a lavorare con poche idee sulla strategia di test. Il codice congelato è considerato un anti-pattern, e a ragione. È costoso in termini di risorse e lavoro manuale.
Il granchio dei test è simile al cono di gelato dei test, ma con una maggiore enfasi sui test E2E e visivi:
Questa strategia di test include un altro aspetto: verifica che l'applicazione funzioni e abbia un bell'aspetto. Il granchio dei test sottolinea l'importanza dei test visivi, definiti nell'articolo precedente. I test di integrazione, suddivisi in test dei componenti e delle API, passano ulteriormente in secondo piano e i test delle unità svolgono un ruolo ancora più secondario. Puoi trovare ulteriori dettagli su questa strategia di test in questo articolo sul granchio dei test.
Sebbene siano più costose, queste due strategie di test hanno il loro posto: ad esempio, in progetti più piccoli in cui sono necessari meno test o è necessario coprire una complessità inferiore. In questo caso, una strategia di test completa incentrata sui test di integrazione potrebbe essere eccessiva.
Sebbene queste due strategie di test siano più costose, hanno il loro posto, ad esempio, in progetti più piccoli che richiedono meno test e non devono coprire molta complessità. In questo caso, una strategia di test su larga scala incentrata sui test di integrazione potrebbe essere inutilmente complessa.
Consigli pratici: definiamo una strategia
Ora conosci le strategie di test più comuni. Hai iniziato con il classico, la piramide dei test, e hai conosciuto i suoi numerosi adattamenti. Ora devi valutarli per il tuo prodotto e decidere quale sia il migliore per il tuo progetto. La risposta a questa domanda dovrebbe iniziare con la frase preferita di tutti: "Dipende". Tuttavia, questo non lo rende meno preciso.
La scelta della strategia di test più appropriata tra quelle descritte, e anche quelle escluse, dipende dalla tua applicazione. Deve essere adatto alla tua architettura, ai tuoi requisiti e, ultimo ma non meno importante, ai tuoi utenti e ai loro requisiti. Tutto questo potrebbe variare da un'applicazione all'altra. È del tutto normale. Ricorda che il tuo obiettivo più importante è servire i tuoi utenti, non una definizione da manuale.
Molto spesso, i test reali sono difficili da separare e definire singolarmente. Persino Martin Fowler stesso sottolinea l'aspetto positivo delle definizioni diverse, come nel caso dei test delle unità. Come afferma correttamente Justin Searls nel suo tweet:
[…] scrivere test espressivi che stabiliscano confini chiari, vengano eseguiti in modo rapido e affidabile e non vadano a buon fine solo per motivi utili.
di Justin Searls
Concentrati sui test che segnalano errori effettivi che gli utenti potrebbero riscontrare e non farti distrarre dal tuo obiettivo. I test devono essere progettati per offrire vantaggi all'utente, non solo per fornire una copertura del 100% o per discutere su quale percentuale di quale tipo di test scrivere.
Concentrati sui test che segnalano errori reali che i tuoi utenti potrebbero riscontrare e non farti distrarre dal tuo obiettivo. I test devono essere progettati per offrire vantaggi all'utente, non solo per fornire una copertura del 100% o per suscitare dibattiti sulla percentuale di un particolare tipo di test da scrivere.