In che modo le persone mantengono la propria suite di test?

In particolare, sono curioso dei seguenti aspetti:

1. Come fai a sapere che i tuoi casi di test sono errati (o obsoleti) e che dovevano essere riparati (o eliminati)? Voglio dire, anche se un caso di test è diventato non valido, potrebbe comunque passare e rimanere in silenzio, il che potrebbe farti credere erroneamente che il tuo software funzioni bene. Quindi, come ti rendi conto di tali problemi nella tua suite di test?

2. Come fai a sapere che la tua suite di test non è più sufficiente e che dovrebbero essere aggiunti nuovi casi di test? Immagino che ciò abbia a che fare con le modifiche ai requisiti, ma esiste un approccio sistematico per verificare l'adeguatezza della suite di test?

Risposta breve: utilizzare strumenti noti che aiutano a mantenere la qualità dei casi di test come la seguente copertura del codice e gli strumenti di qualità del codice: Cobertura, PMD, Sonar, ecc. Che ti aiuteranno a notare quando un componente critico del programma non è sufficientemente testato. Inoltre, scrivi test di integrazione, che molto probabilmente si rompono per primi ogni volta che qualcosa va storto.

Risposta lunga:

Come fai a sapere che i tuoi casi di test sono errati (o obsoleti) e che dovevano essere riparati (o eliminati)? Voglio dire, anche se un caso di test è diventato non valido, potrebbe comunque passare e rimanere in silenzio, il che potrebbe farti credere erroneamente che il tuo software funzioni bene. Quindi, come ti rendi conto di tali problemi nella tua suite di test?

• Utilizzando strumenti di copertura del codice come Cobertura , è possibile rilevare che i casi di test per una determinata classe o metodi complessi non sono più sufficienti. Non è necessario raggiungere il 100% di copertura del codice ovunque e nella maggior parte dei casi sarà difficile da raggiungere e non necessariamente utile; ma i test per gli aspetti più critici di un programma dovrebbero essere mantenuti con un obiettivo di almeno l'80% della copertura del codice.
• Utilizzando strumenti di compilazione e integrazione continui , come Jenkins di cui sono molto affezionato, in combinazione con il plug-in Sonar , è possibile impostare trigger che inviano e-mail e altri tipi di avvisi alle persone responsabili delle ultime modifiche. Vari grafici e statistiche (Sonar utilizza anche Cobertura tra molti altri strumenti) aiutano i revisori dei codici e gli sviluppatori di test case a concentrarsi su ciò che è critico.

Come fai a sapere che la tua suite di test non è più sufficiente e che dovrebbero essere aggiunti nuovi casi di test? Immagino che ciò abbia a che fare con le modifiche ai requisiti, ma esiste un approccio sistematico per verificare l'adeguatezza della suite di test?

Quello che ho scritto per la prima domanda fa parte della risposta per la tua seconda domanda. Aggiungerò anche i seguenti punti qui:

• Scrivi casi di test di integrazione (o casi "aziendali" se preferisci) oltre ai casi di test. È molto probabile che questi cambino / rompano prima perché spesso dipendono da più classi / metodi. E poiché si rompono spesso, è meno probabile che venga dimenticato. L'unico approccio / metodologia che, dalla mia esperienza personale, aiuta a scrivere buoni test è lo sviluppo guidato dai test . In particolare se la persona che scrive il test case NON è la stessa persona che scrive il codice per esso. Anche scrivere buoni casi di test usando TDD richiede tempo, ma i risultati, almeno per me, sono stati estremamente soddisfacenti.
• Ogni volta che viene fuori un bug, scrivi la correzione e il test case che ne deriva. Il caso di test dovrebbe riguardare solo questo particolare bug. Dal momento che hai completamente coperto il codice che è responsabile del bug, non dovrebbe più venire fuori.

Non esiste alcun modo per assicurarsi che i casi di test siano corretti, se non concentrandosi molto bene durante la loro creazione: comprendere i requisiti, comprendere il codice e assicurarsi che siano d'accordo. Il punto di avere una suite di test è che devi farlo solo una volta, e da quel momento in poi puoi semplicemente rieseguire i test e verificarne il superamento, mentre senza una suite di test dovresti concentrarti molto duramente tutto il tempo , ovvero ogni volta che fai qualcosa alla tua base di codice. Ma il problema fondamentale di dover assicurarsi di fare la cosa giusta in primo luogo rimane: i computer semplicemente non sono abbastanza intelligenti da sollevarci da quel compito.

Pertanto, (1) se la suite di test è incompleta, non esiste un modo semplice per vederlo. L'analisi della copertura del codice può dimostrare che alcune righe di codice non vengono mai eseguite, ovvero che la suite è in qualche modo carente, ma non quanto grave sia tale carenza e non può mai dimostrare che sia sufficiente. Anche con una copertura del codice del 100% non hai alcuna garanzia che tutti gli stati rilevantidel sistema viene esercitato e la copertura statale completa è inaccettabile per qualsiasi sistema realistico a causa del numero combinatorio di stati che potrebbero esistere. Una buona tecnica per assicurarsi che il test case sia almeno corretto per verificare ciò che si desidera controllare è scrivere il test, verificare che non abbia effettivamente esito positivo, scrivere / modificare il codice e quindi verificare che ora passi. Da qui l'entusiasmo per lo sviluppo test-driven: ti permette di essere abbastanza sicuro che un singolo test fa la cosa giusta, e se crei l'intera base di codice in quel modo, puoi ottenere un livello di sicurezza simile anche in un sistema di grandi dimensioni.

(2) Una suite di test diventa normalmente insufficiente ogni volta che cambiano i requisiti - non devi indovinare. Se il cliente desidera che un determinato comportamento venga modificato e che i test abbiano esito positivo sia prima che dopo la modifica, chiaramente non esercitavano quel particolare rapporto input / output.

Per quanto riguarda i sistemi legacy che non hanno copertura di test o dove non si conosce la copertura, non esiste una prova formale, ma (consulenza dei genitori: segue l'opinione personale!) Parlando per esperienza, è estremamente probabile che i test non sono adeguati. Quando i test sono visti come un'attività post-pratica, facoltativa, che migliora la qualità ma non proprio necessaria, tende ad essere incompleta e non sistematica perché l'incentivo per assicurarsi che i test stiano al passo con la base di codici non è giusto ci sono.