Il valore degli strumenti di copertura del codice di test

Question

Abbiamo iniziato a utilizzare Part Cover per tenere traccia della copertura del codice di test della nostra applicazione. IMO è un ottimo strumento per ottenere un punteggio complessivo per i tuoi test e per evidenziare le aree di test dove potresti essere stato un po 'pigro con i test, ma oggi ho scritto un test e ho capito che non testava nulla di utile, semplicemente aumentava la mia copertura!

Se si è TDD, si scrive solo il codice per superare un test ei test descrivono dettagliatamente tutte le funzionalità richieste dall'applicazione. Quindi in questo scenario è ancora molto utile avere un'analisi della copertura?

Per quelli di voi che hanno gli strumenti di copertura, come si fa religiosamente se effettuata a mantenere la copertura al 100% e non si trova mai scrivere i test che non davvero prova nulla, ma solo per mantenere la copertura fino ? Non è una cosa negativa ?

Answer 1

Gli strumenti di copertura devono essere utilizzati solo per dirvi cosa è stato testato non. Lo scenario che hai indicato illustra il motivo per cui non puoi fare affidamento su di loro per mostrarti quale codice è stato testato. Scrivere dei test solo così la copertura è al 100% è inutile (come sospettavate), ed è così facile da giocare che questa non è davvero una metrica utile. Cercavo di rimanere al 100% o vicino, ma sono arrivato alla stessa conclusione che hai fatto. Stavo scrivendo dei test che non testavano davvero nulla solo così i numeri erano corretti. Usa gli strumenti per individuare aree che non hai ancora testato, quindi scrivi buoni test o accetta il fatto che quelle parti del codice non sono critiche.

Answer 2

Buona razionalizzazione;) Ma dopo tutto siamo umani, e io per primo dormo molto meglio di notte sapendo che un metodo o un percorso non testato non è stato messo in produzione.

Answer 3

Se stai facendo puro TDD, c'è meno valore nella copertura del codice perché, come dici tu, scrivi solo codice dai test, quindi dovresti essere comunque al 100%. ma poi, probabilmente è piuttosto raro (ea volte non è possibile) farlo in modo così puro.

se non si sta facendo puro TDD, il 100% è un obiettivo piuttosto irrealistico. Di solito cerco di seguire il metodo di Roy Osherove e testare solo le cose con la logica (ad esempio non getter/setter o pass-through diretti). Ma poi, più in alto è sempre meglio, e può essere allettante mettere un paio di test in più per aumentare quella copertura ..!

Answer 4

Farò l'avvocato del diavolo: se aumentare la copertura significava scrivere un test che "non testava nulla di utile", allora perché c'era quel codice? Per me, questo sarebbe un argomento per rimuovere alcuni codici mainline.

Oppure per sviluppare un test che faccia qualcosa di utile. Ad esempio, potresti considerare che non è utile testare setter e getter. Nemmeno io. Tuttavia, quei metodi dovrebbero essere testati mentre si prova qualcos'altro. Altrimenti, di nuovo, perché sono lì?

Ma si alza un buon punto che gli strumenti di copertura non dovrebbero essere un fine a se stessi. Soprattutto perché non possono dirti quale codice devi scrivere.

Sono andato più in dettaglio qui: http://www.kdgregory.com/index.php?page=junit.coverage