Modo automatico per rilevare i test che non possono fallire, registrati per ottenere una copertura minima del codice?

Question

Ho un dev, che aggirerà la nostra copertura di codice scrivendo test che non falliscono mai.

Il codice è semplicemente atroce, ma i test non lo prendono mai perché affermano (vero).

Revisiono il codice, ma non riesco sempre a far funzionare tutti quanti per loro. Come si fa a motivare le persone così a creare un buon software?

Esiste un plug-in di build per rilevare i test che non possono fallire?

C #, test mbUnit.

Answer 1

La vera motivazione viene dall'interno. Alcune persone giocheranno al sistema ogni volta che avranno a volte per nessun altro motivo possibile. Altri lo fanno semplicemente perché sono hack.

Detto questo, supponendo che tu sia il gestore, devi avere un "vieni a Gesù". incontro con il dev. Se ancora non funziona, c'è sempre la porta.

Se non sei il gestore, prendi i canali appropriati.

Answer 2

Penso che tu abbia quasi risposto alla domanda da solo lì. Se hai qualcuno che lavora per te o con te (non sei sicuro di non essere il manager di questo sviluppatore), allora se non stanno svolgendo il lavoro correttamente, sicuramente ci sono procedure disponibili per chiarire a questa persona che loro non stanno producendo lavori secondo uno standard accettabile.

Lo sviluppatore è nuovo su TDD? Forse hanno bisogno di lezioni per scrivere buoni test ecc. Altrimenti hanno bisogno di un calcio nel culo e hanno sottolineato che i test sono come se non fossero più importanti del codice che sta producendo.

Oh sì, e per quanto riguarda il plug-in, dimentica che, lo stesso codice di revisione che stai facendo dovrebbe essere abbastanza buono.

Answer 3

Dovresti davvero specificare la lingua / il framework che stai usando.

Nel caso più semplice, suppongo che dovrebbe essere facile rilevare stringhe assert (true) con semplice grep -ping.

Answer 4

Puoi sempre provare a eseguire un test con Garbage per i valori di configurazione dell'applicazione.

Qualunque test superato è sospetto?

Answer 5

Invece di dedicare tempo alla ricerca di test che non possono fallire, che ne dici di estendere un po 'i test - fai fallire il codice in molti modi. Sarebbe

• Mostragli come scrivere test migliori
• Costringilo a correggere il suo codice e impedisce che vengano registrati più codici errati

Un pezzo di codice errato che devi usare sarebbe un buon punto di partenza - devi essere sicuro che funzioni ...

Answer 6

Prendi l'interfaccia che sta testando e riducila nella sua forma più semplice. In altre parole, prendi le firme di classe / metodo e aggiungi solo il codice necessario per compilare oltre. Esegui i suoi test contro quello. Chiedigli perché i suoi test stanno superando quando il programma non fa nulla.

Answer 7

La revisione del codice, da parte di due o più sviluppatori che sono già stati testati infetti, è probabilmente il modo migliore per mettere in discussione lo sviluppatore per vedere che i test di unità automatizzati non sono davvero così difficili, né insoliti. Avere due sviluppatori infetti da test su ogni recensione rafforzerà l'importanza dei test unitari di qualità per lui. Inoltre, assegnargli recensioni sul codice di altri sviluppatori che è ben testato lo aiuterà a imparare come testare le unità.

Dovresti dare un'occhiata a test di mutazione , per rilevare test deboli. Nester , (l'equivalente .Net di Jester ) è uno strumento che potresti trovare utile.

Per favore facci sapere come va!

Aggiornamento: mi sono imbattuto: " Perché la maggior parte degli sviluppatori non scrive ancora unit test? " e ha pensato che sarebbe una buona lettura anche qui.

Answer 8

Penso che tu debba provare a convincerlo a scrivere prima un test fallito. Prova a metterlo in questa abitudine. Spesso i nuovi test unitari hanno difficoltà a scriverli.

Inoltre ci sono alcuni strumenti che possono aiutarti a " esplorare tutti i possibili percorsi di codice " ;. Ti suggerisco di dare un'occhiata a PEX che genererà test automatizzati e molto probabilmente romperà il suo codice ... Anche se questo potrebbe non essere un soultion ottimale, prova a promuovere il concetto di un condiviso base di codice.

Fai accoppiare i tuoi sviluppatori al programma, è molto più difficile " essere pigro " quando stai lavorando con qualcun altro sulla stessa funzione e si diffonderà la proprietà del codice. Sembra che tu non lo stia facendo, poiché parli di " suo " codice. Può essere sopprimere quanto puoi fare se ci sono 2 persone che lavorano nello stesso lavoro, aumenterà la qualità di molto.

Anche i test unitari non sono il santo graal per sradicare tutti i problemi ... Dovrebbero essere uno degli strumenti che hai a tua disposizione.

Qual è il tuo requisito di copertura del codice?