Ora so che le persone potrebbero considerare questa domanda duplicata o posta più volte, nel qual caso apprezzerei un collegamento a domande pertinenti con la risposta alla mia domanda.
Sono stato recentemente in disaccordo con alcune persone sulla copertura del codice. Ho un gruppo di persone che vogliono far cadere il nostro team guardando la copertura del codice sulla base dell'argomento che una copertura del 100% non significa test di buona qualità e quindi un codice di buona qualità.
Sono stato in grado di respingere vendendo l'argomento secondo cui la copertura del codice mi dice cosa non è stato testato di sicuro e ci aiuta a concentrarci su quelle aree.
(Quanto sopra è stato discusso in modo simile in altre domande SO come questa - /programming/695811/pitfalls-of-code-coverage )
L'argomento di queste persone è che il team reagirebbe creando rapidamente test di bassa qualità e quindi perdere tempo senza aggiungere una qualità significativa.
Mentre capisco il loro punto di vista, sto cercando un modo per rendere più solida la copertura del codice introducendo strumenti / framework più solidi che si occupino di più criteri di copertura (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc) .
Quello che sto cercando è un suggerimento per una combinazione di tali strumenti di copertura del codice e pratiche / processi da accompagnare che possa aiutarmi a contrastare tali argomenti mentre mi sento a mio agio con la mia raccomandazione.
Accolgo con favore anche eventuali commenti / suggerimenti di accompagnamento basati sulla tua esperienza / conoscenza su come contrastare tale argomento, perché mentre soggettiva, la copertura del codice ha aiutato il mio team a essere più consapevole della qualità del codice e del valore dei test.
Modifica: per ridurre la confusione sulla mia comprensione della debolezza della copertura tipica del codice, voglio sottolineare che non mi riferisco agli strumenti Statement Coverage (o alle linee di codice eseguite) (ce ne sono molti). In effetti ecco un buon articolo su tutto ciò che non va: http://www.bullseye.com/statementCoverage.html
Stavo cercando qualcosa di più di una semplice dichiarazione o copertura di linea, approfondendo più criteri e livelli di copertura.
Vedi: http://en.wikipedia.org/wiki/Code_coverage#Coverage_criteria
L'idea è che se uno strumento può dirci la nostra copertura sulla base di più criteri, ciò diventa una ragionevole valutazione automatizzata della qualità del test. Non sto assolutamente cercando di dire che la copertura della linea sia una buona valutazione. In realtà questa è la premessa della mia domanda.
Modifica:
Ok, forse l'ho proiettato un po 'troppo drammaticamente, ma hai capito. Il problema riguarda l'impostazione di processi / politiche in generale in tutti i team in modo omogeneo / coerente. E la paura è generale di come garantire la qualità dei test, come allocare tempo garantito senza avere alcuna misura ad esso. Quindi mi piace avere una caratteristica misurabile che, se eseguito il backup con processi appropriati e gli strumenti giusti, ci consentirebbe di migliorare la qualità del codice pur sapendo che il tempo non viene speso in processi dispendiosi.
EDIT: finora quello che ho dalle risposte:
- Le revisioni del codice dovrebbero coprire i test per garantire la qualità dei test
- Test La prima strategia aiuta a evitare i test scritti dopo il fatto per aumentare semplicemente la copertura%
- Esplorazione di strumenti alternativi che coprono criteri di test diversi dalla semplice dichiarazione / linea
- L'analisi del codice coperto / numero di bug rilevati contribuirebbe ad apprezzare l'importanza della copertura e fornire un caso migliore
- Soprattutto, fidati del contributo del Team per fare la cosa giusta e lottare per le loro convinzioni
- Blocchi coperti / N. di test - Discutibile ma con un certo valore
Grazie per le fantastiche risposte finora. Li apprezzo davvero. Questo filo è meglio di ore di brainstorming con i poteri che sono.