Scenario ipotetico: il codebase viene esercitato da test unitari eseguiti da un build-bot TeamCity, che utilizza anche lo strumento dotCover incorporato per fornire le metriche di copertura. La compilazione fallirà se viene coperto meno del X% del codice.
Uno sviluppatore senza scrupoli che esegue NCrunch (o un commit pre-testato in TC) vede che il prossimo check-in ridurrà la percentuale di copertura sotto la soglia e interromperà la build, perché non ha scritto buoni test unitari (TDD o altro). Quindi, scrive un nuovo test che esegue alcune righe di codice che gli spettacoli NCrunch non sono coperti, ma non fa affermazioni sul loro comportamento. I test passano per impostazione predefinita (poiché il codice eseguito non fa eccezioni), la copertura rimane al di sopra del X% e per trovare il problema, qualcuno deve scoprire il test, ispezionarlo e vedere che non ci sono asserzioni (o asserzioni significative) fatte durante la sua esecuzione .
Poiché al momento non abbiamo un processo di revisione del codice e sarebbe dannoso per la produttività eseguire revisioni prima di ogni commit, voglio che questo comportamento interrompa la creazione. Se il test runner esegue un metodo contrassegnato con un attributo [Test] (stiamo usando NUnit) e, al completamento, vede che il codice non ha effettuato chiamate ai metodi Assert di NUnit, né ha lanciato ExpectedException, TC dovrebbe aumentare Cain. Idealmente, lo strumento sarebbe abbastanza intelligente da scoprire anche che tutte le asserzioni sono vere per definizione, come Assert.AreEqual(1,1); , e falliscono la costruzione in un modo simile.
C'è qualcosa di "preconfezionato" che posso collegare a TeamCity, o un modo in cui posso configurare le sue metriche di copertura / copertura integrate per trovare questo tipo di comportamento scorretto, a meno di eseguire un'analisi del codice statico personalizzata ? Ovviamente lo troveremo alla fine , ma nel nostro ambiente (piccolo team di sviluppo interno) potrebbero esserci solo uno o due sviluppatori che hanno familiarità con l'intera base di codice di una determinata applicazione, e quindi questo palese terminare i controlli di qualità dei test non può accadere fino a quando il responsabile non è più da tempo e qualcun altro assume la proprietà primaria del codebase.