Caveat emptor: perché stai implementando gli standard di test?
L'unica risposta corretta qui è quella di valutare gli standard del test in confronto a quello che stai cercando di uscire dal test.
Esempio: se stai provando ad avere un'applicazione medica incorporata priva di difetti (come un pacemaker), allora i tuoi standard sono probabilmente troppo bassi. Se stai scrivendo prototipi di applicazioni da buttare via, come le demo, i tuoi standard sono decisamente troppo alti.
Un altro esempio: se il tuo team è molto anziano e hai bisogno di scrivere codice snello e veloce, probabilmente altre forme di test sono più importanti dei test unitari. Se hai una squadra junior che è incline a fare molti errori e vuoi implementare standard difensivi, allora questa strategia non sembra abbastanza strong.
Detto questo, direi che con gli standard che stai suggerendo, non otterrai molto dai test:
-
La copertura del codice parziale è meglio di niente, ma se introduci complessità a causa dei test, potresti avere un conteggio dei difetti aumentato nelle parti non testate.
-
La copertura del codice parziale non consente alla tua squadra di refactoring impunemente.
-
Dare agli sviluppatori il tempo di scrivere i test è buono, ma chiedere loro di scrivere prima i test è molto meglio, e dare loro dei test di accettazione è probabilmente meglio nel tuo caso.
Come puoi vedere, le mie risposte sono molto generali, ma rappresentano la mia esperienza ripetuta. In nessun caso gli indici mix-and-match mi sono stati utili.
Ci sono due usi della copertura del codice, per quanto ne so:
-
quando il tuo codice ha una copertura ridotta (ad esempio < 85%), la copertura del codice è utile solo per identificare i luoghi che necessitano di testare l'amore. La percentuale è francamente irrilevante.
-
quando la copertura del tuo codice è alta, puoi utilizzare una metrica di copertura minima per trasformare la compilazione in rosso. Sì, l'alta copertura non garantisce la correttezza, ma una copertura bassa è certamente correlata con più difetti, quindi una volta che il tuo team ha raggiunto standard elevati è bene se può mantenerli.
La tua strategia di rendere il controllo della copertura discreta funzionerà solo se la squadra ha già una copertura di codice elevata, altrimenti dovranno sapere esattamente cosa coprire, nel qual caso dovranno disporre di una linea per linea costantemente disponibile mappa della copertura che hanno!
Infine, se hai un sacco di codice non testato semplicemente dando ai tuoi sviluppatori il tempo di scrivere test per nuove funzionalità non risolverà i problemi di copertura iniziale. Questo è importante, perché per rendere testabile il nuovo codice, il tuo team dovrà refactoring il vecchio codice , e per farlo con sicurezza ... devono prima testare il vecchio codice . Non hai specificato se questo è per un progetto greenfield o uno brownfield: fa una grande differenza.
Consentitemi di rispondere alle ulteriori informazioni fornite.
- Vuoi abbreviare i tuoi cicli di feedback;
- Vuoi motivare la tua squadra;
- Vuoi che il tuo team scriva test;
- Vuoi ridurre il conteggio degli errori per le nuove funzionalità;
- Vuoi ridurre le regressioni;
Questi obiettivi sono lodevoli ma molto difficili da ottenere in una situazione ideale, per non parlare di uno scenario di applicazioni legacy complicato.
Quello che ti suggerisco è di concentrarti su quello più importante e di farlo prima e poi passare a quello successivo. Assicurati che, una volta avviato il rearchitecting dell'applicazione, le qualità architettoniche siano ben definite (ad esempio, le prestazioni sono una funzionalità).
Ad esempio:
-
Metti insieme il tuo team di test e sviluppo e falli tornare con un buon piano per testare automaticamente l'applicazione. La soluzione deve essere raggiungibile entro alcuni limiti (tipicamente del tempo). Non vuoi una copertura del 100% in questa fase. Semplicemente vuoi che venga eseguito un setup di test automatico, con i test quick-win eseguiti su di esso.
-
Una volta completato quanto sopra, imposta alcuni obiettivi concreti sulla qualità e lascia che il team proponga la migliore strategia per raggiungerli. Tipicamente, verranno proposti alcuni test verticali , come test di integrazione. Misura tutto, sii trasparente, monitora successi e fallimenti. Vuoi qui la copertura del codice, ma anche i grafici di conteggio degli errori, ecc.
-
Una volta eseguito quanto sopra, e se TDD è appropriato, refactoring, rearchitecture e unit test eseguono il codice legacy (wrap e refactor) e sviluppano nuove funzionalità usando TDD.
-
...