Una piramide di test più semplice: ottenere il massimo dai test

Articoli sulla home page di InfoQ Una piramide di test più semplice: ottenere il massimo dai test

Questo articolo in giapponese

10 aprile 2023 10 minuti di lettura

di

Tyson Volentieri

recensito da

Matt Campbell

Gli sviluppatori utilizzano molte etichette diverse per descrivere i propri test automatizzati (unità, integrazione, accettazione, componente, servizio, end-to-end, interfaccia utente, database, sistema, funzionale o API). Ognuna di queste etichette ha un significato semantico diverso, descrivendo l'ambito del test, i tipi di azioni intraprese dal test, l'oggetto del test o i collaboratori del soggetto. Di solito non siamo d'accordo sul significato di ciascuna di queste etichette e le discussioni sulla loro definizione tendono ad essere inutili.

Piuttosto che discutere su quali etichette utilizzare e come definirle, ho trovato più utile utilizzare uno dei due aggettivi per etichettare ciascun test: lento o veloce. Queste etichette possono essere altrettanto utili quando si decide la composizione di una suite di test, consentendo allo stesso tempo agli sviluppatori di classificare oggettivamente i test senza argomenti improduttivi.

Codifica, distribuisci e scala Java a modo tuo.Microsoft Azure supporta il tuo carico di lavoro con numerose scelte, sia che tu stia lavorando su un'app Java, un server di app o un framework. Saperne di più.

La scelta delle etichette di test ha un'influenza importante sulla composizione di una suite di test. Gli sviluppatori li usano per sapere quando scrivere un test per un dato comportamento, per sapere quale tipo di test scrivere e per valutare l'equilibrio della suite di test nel suo insieme. Quando sbagliamo, ci ritroviamo con una suite di test che non fornisce una copertura accurata o la fornisce a un costo inaccettabile.

Quando dovresti scrivere un test per un determinato pezzo di codice di produzione? Gli sviluppatori che, come me, praticano l'Extreme Programming (XP) o il Test Driven Development (TDD) spesso rispondono a questa domanda con “sempre”. Tuttavia, non tutte le parti di codice dovrebbero essere testate automaticamente. Per ogni test proposto, innanzitutto, valutare i costi di scrittura del test rispetto ai benefici.

Non sto difendendo la scrittura dei test. In effetti, per la maggior parte dei test, si tratta di un controllo rapido e la risposta è sì. Tuttavia, questo controllo è utile, soprattutto se un test è lento da eseguire, lento da scrivere o difficile da mantenere. In questi casi ponetevi alcune domande.

Il test è costoso a causa di una decisione progettuale? È possibile eseguire il refactoring del codice per adattarlo meglio ai test? I tuoi test sono i primi consumatori del tuo codice di produzione. Rendere il codice più semplice da testare spesso ne facilita l'utilizzo, migliorando la qualità della base di codice.

Il test è costoso a causa dell’approccio di test? Un approccio di test diverso renderebbe questo test più facile da scrivere? Prendi in considerazione l'utilizzo di controfigure di test come falsi o simulazioni al posto dei collaboratori. Se i tuoi test necessitano di una configurazione complicata, estraila in uno scenario di test che può essere riutilizzato tra i test.

Fai attenzione a non abusare dei doppi test, poiché non forniscono la stessa sicurezza dei veri collaboratori. A volte questo calo di fiducia vale la facilità di configurazione, la riduzione della durata del test o l'aumento dell'affidabilità. Tuttavia, fare eccessivo affidamento sui test double potrebbe accoppiare i test con l'implementazione, risultando in una suite di test che fornisce scarsa confidenza e che inibisce il refactoring.

Il test è costoso perché il comportamento è intrinsecamente difficile da testare? In tal caso, considera l'importanza della funzionalità che stai testando. Se si tratta di una funzionalità fondamentale che coinvolge l'elaborazione dei pagamenti, il test potrebbe valere il costo. Se si tratta di un caso limite bizzarro nella logica di visualizzazione, dovresti riconsiderare se scrivere o meno il test.

Il test è costoso perché fallisce in modo imprevedibile? Se è così devi rimuoverlo, riscriverlo per renderlo più affidabile o separarlo dal resto della tua suite di test. Affinché una suite di test fornisca un feedback utile, è necessario essere certi che gli errori dei test rappresentino un comportamento indesiderato. Se ritieni che un test sia necessario e non possa essere reso prevedibile, spostalo in un'altra suite di test eseguita meno frequentemente.