Eliminare o commentare test JUnit non funzionanti?

Question

Attualmente sto sviluppando uno script di compilazione di elementi di configurazione per un'applicazione legacy. Sono disponibili test JUnit sporadici e integrerò un'esecuzione JUnit di tutti i test nella build CI. Tuttavia, mi chiedo cosa fare con i 100 errori che sto incontrando nei test JUnit non mantenuti. Faccio:

1) commentarle come essi sembrano avere ragionevole, se non più mantenuto, la logica di business in loro, nella speranza che qualcuno alla fine li uncomments e corregge le

2) cancellarli come il suo improbabile che qualcuno li aggiusterà e il codice commentato verrà ignorato o sarà ingombrante per sempre

3) Rintraccia chi ha lasciato questo pasticcio tra le mani e colpiscilo sulle teste con le stampe del codice (che a causa di l'odore a lungo termine sarà sufficientemente adatto al compito) mentre predica i vantaggi di una base di codice ben mantenuta e testata dell'unità

Answer 1

• Commentale in modo che possano essere riparati in seguito.
• Generare rapporti di copertura di prova (con Cobertura ad esempio). I metodi che avrebbero dovuto essere coperti dai test che hai commentato saranno indicati come non coperti dai test.

Answer 2

Se si compilano ma falliscono: lasciarli in. Ciò ti porterà una buona cronologia dei miglioramenti dei test nel tempo quando si utilizza CI. Se i test non vengono compilati ma interrompono la generazione, commentali e attacca gli sviluppatori per risolverli.

Questo ovviamente non preclude l'utilizzo dell'opzione 3 (colpendoli sopra la testa), dovresti farlo comunque, indipendentemente da ciò che fai con i test.

Answer 3

Se si utilizza Junit 4, è possibile annotare i test con @Ignore annotation.

Se si utilizza JUnit 3 è possibile rinominare i test in modo che non inizino con test.

Inoltre, provare a correggere i test per la funzionalità che si sta modificando in modo da non rendere il pasticcio di codice più grande.

Answer 4

Non conosco la posizione dell'azienda, ma se è possibile lasciarli e archiviare i problemi come errori nel sistema di ticket. Lascia fare agli sviluppatori di risolverli o rimuovere i test.

Se ciò non funziona rimuovili (hai il controllo di versione, giusto?) E chiudi il ticket con un commento come "rimossi i test di junit che falliscono apparentemente non saranno corretti" o qualcosa di un po 'più educato.

Il punto è che i test di junit sono codici di applicazione e come tali dovrebbero funzionare. Questo è ciò per cui gli sviluppatori vengono pagati. Se un test non è più appropriato (qualcosa che non esiste più è stato testato) gli sviluppatori dovrebbero segnalarlo e rimuovere il test.

Answer 5

Seguire il principio no broken window e prendere qualche azione verso una soluzione del problema. Se non è possibile correggere i test, almeno:

1. Ignorarli dai test di unità (ci sono diversi modi per farlo).
2. Immettere il numero di problemi necessario e assegnare le persone per correggere i test.

Poi, per evitare tale situazione si ripeta in futuro, installare un plug-in simile a Hudson Game Plugin. Le persone ricevono punti assegnati durante l'integrazione continua, ad es.

• -10 rompere la build < - peggio
• -1 rompere un test
• +1 posto un test
• ecc

strumento davvero interessante per creare un senso di responsabilità sui test unitari all'interno di una squadra.

Answer 6

Si dovrebbe sicuramente disabilitarli in qualche modo per ora. Che ciò sia fatto commentando, cancellando (supponendo che tu possa recuperarli dal controllo del codice sorgente) o altri mezzi spetta a te. Non vuoi che questi test non funzionanti siano un ostacolo per le persone che cercano di presentare nuove modifiche.

Se ce ne sono abbastanza che si sente di poterli aggiustare da soli, ottimo - fallo. Se ce ne sono troppi, sarei propenso a utilizzare un approccio "crowdsourcing". Presenta un bug per ogni test fallito. Cerca di assegnare questi bug agli attuali proprietari/autori dei test/codice testato se possibile, ma se è troppo difficile determinarli, la selezione casuale va bene fintanto che dici alle persone di riassegnare i bug che sono stati assegnati in modo errato a loro. Quindi incoraggia le persone a correggere questi bug dando loro una scadenza o avvisando periodicamente tutti i progressi e incoraggiandoli a correggere tutti i bug.

Answer 7

Un sistema CI che è rosso fisso è piuttosto inutile. Il vantaggio principale è mantenere una barra di qualità, e questo è reso molto più difficile se non c'è transizione per contrassegnare un calo di qualità.

Pertanto, lo sforzo immediato dovrebbe essere quello di disabilitare i test in errore e creare un ticket di tracciamento/elemento di lavoro per ciascuno. Ognuna di queste è risolta, tuttavia si esegue il triage - se a nessuno interessa il test, sbarazzarsi di esso. Se l'errore rappresenta un problema che deve essere risolto prima della spedizione, lasciare il test disabilitato.

Una volta che ci si trova in questo stato, ora è possibile fare affidamento sul sistema CI per dirvi che è necessaria un'azione urgente: ripristinare l'ultima modifica o immediatamente mettere una squadra a risolvere il problema o qualsiasi altra cosa.

Answer 8

I non superano le prove JUnit indicano che o

1. Il codice sorgente in prova è stato lavorato senza le prove sono mantenuti. In questo caso vale la pena considerare l'opzione 3, oppure
2. Hai un vero fallimento.

In entrambi i casi è necessario correggere/rivedere i test/la fonte. Poiché sembra che il tuo compito sia creare il sistema di CI e non correggere i test, nella tua posizione lascerei una bomba a tempo nei test. È possibile ottenere molto di fantasia con i metodi annotati con JUnit 4 (qualcosa come @IgnoreUntil(date="2010/09/16")) e un corridore su misura, in modo da oppure si può semplicemente aggiungere un un'istruzione if alla prima riga di ogni prova:

if (isBeforeTimeBomb()) { 
    return; 
    } 

Dove isBeforeTimeBomb() può semplicemente controlla la data corrente rispetto a una data futura a tua scelta.Quindi segui i consigli forniti da altri qui e notifica al tuo team di sviluppo che la build è ora verde, ma è probabile che esploda in X giorni a meno che i test timebomb non vengano corretti.