Originariamente, è compito dello sviluppatore scrivere il test, ma ho notato che in molti casi / sviluppatori e-maturi questi casi non forniscono nemmeno una copertura dell'80%.
Che ne dici di avere un responsabile del QA dedicato a scrivere TUTTI i test per un determinato progetto anziché lo sviluppatore?
Ci sono dei contro?
In Test-Driven Development, i test devono essere scritti dallo sviluppatore. Altrimenti, qualcuno che non sia lo sviluppatore sta guidando lo sviluppo.
Quindi, non appena svolgi il compito di scrivere test per un non sviluppatore, quella persona diventa uno sviluppatore.
La mia esperienza in TDD è che scrivere il codice di prova è spesso più difficile o più difficile rispetto alla scrittura del codice di produzione. Quindi, se disponi di risorse in grado di scrivere buoni test di unità / codice di test di integrazione, dovrebbero scrivere il codice di produzione che fa passare quei test.
Il lavoro di QA è di eseguire un tipo di test completamente diverso (cioè test di usabilità / integrazione). Non hanno davvero bisogno di conoscere le tecnologie utilizzate nel codice.
Se sei preoccupato per la copertura dei codici bassi, devi disciplinare i tuoi sviluppatori. Ad esempio, interrompere il lavoro su qualsiasi nuova funzionalità, fino a quando la copertura del codice aumenta. Alcune organizzazioni arrivano fino ad avere un hook pre-commit sul proprio repository che non consente il codice scoperto di check-in.
Ultimo ma non meno importante, nel TTD "puro", non dovrebbe esserci alcun codice scoperto (dal momento che si scrivono prima i test). Tuttavia ci sono casi (anche se la gente ne discute) dove la copertura del codice più bassa è accettabile. Alcuni sostengono, ad esempio, che scrivere test per getter / setter di POJO è una perdita di tempo.
those cases are not giving even 80% coverage
Potrebbe trattarsi di un problema di gestione.
Oppure potrebbe essere irrilevante.
In primo luogo, la differenza tra l'80% e il 100% di copertura è probabilmente un costo molto basso per un beneficio molto ridotto.
"Copertura" può significare qualsiasi cosa. Linee di codice, percorsi logici, ecc. Suppongo che tu intenda linee di codice (non percorsi logici).
Alcuni percorsi logici sono abbastanza ben collaudati "tramite ispezione". Il codice è ovvio, non ha istruzioni if, ha una complessità molto, molto bassa e probabilmente non ha bisogno di un test aggiuntivo.
Il 20% in più di test non rappresenta sempre il 20% in più di qualità.
Seconda. È un problema di gestione. Se la direzione vuole una copertura del 100%, deve mettere in atto un sistema di premi che premia una copertura del 100% invece di "sufficiente per pubblicare" una copertura dell'80%.
L'aggiunta di persone QA per scrivere più test non sarà di grande aiuto.
L'aggiunta di sviluppatori per scrivere più test è ciò che sarà richiesto per ottenere una copertura del test del 100%.
Il test dell'unità IMHO non è un processo di controllo qualità. Si tratta più di accelerare lo sviluppo (riducendo il ciclo di feed back per gli sviluppatori). Dovrebbe essere fatto dalla persona che scrive il componente (aka unità) con un focus sull'utilizzo dei componenti (da parte di un altro sviluppatore).
Il test funzionale è un processo di controllo della qualità che può e deve essere svolto da un team di controllo qualità. Questi possono essere fatti dallo sviluppatore ma uno sviluppatore non esperto sarebbe meglio in quanto lo sviluppatore potrebbe non sapere tutti i modi in cui un utente potrebbe utilizzare l'applicazione.
Entrambi possono essere eseguiti in modalità TDD.
TDD non è solo un test, ma riguarda anche il design. Scrivere codice solo per superare i test porta solitamente a un codice più piccolo e gestibile. Se deleghi a qualsiasi altra persona di scrivere i test, delegherai anche la responsabilità di creare un buon codice.
Dovresti anche notare che la copertura non ti dirà della qualità del codice e non ti dirà se le regole del dominio sono coperte.
Se hai bisogno di una copertura almeno dell'80%, devi fare un paio di cose:
Infine, comprendi che esiste una differenza tra i percorsi di esecuzione previsti e i percorsi di esecuzione non desiderati . Nel processo di scrittura del codice guidato da test, potresti aver provato che hai bisogno di una coppia di istruzioni if indipendenti. Di conseguenza ci sono test per due dei potenziali quattro percorsi di esecuzione disponibili. Aggiungi un'altra dichiarazione if se indipendente e hai un potenziale per otto percorsi di esecuzione (cioè aumenta in modo esponenziale).
Comprendi che TDD non prevede necessariamente ogni potenziale percorso di esecuzione, quindi ci sono un certo numero di test che potrebbero dover essere scritti per essere completi ma non scritti perché non c'era un bisogno per testare quel percorso. In breve, TDD non garantisce la copertura, ma garantisce che ci sia almeno un test per dimostrare la ragione d'eter per il codice che esiste.
Leggi altre domande sui tag tdd development-process