Devo rompere intenzionalmente la build quando si trova un bug in produzione?

La nostra strategia è:

Verifica un test non riuscito, ma annotalo con @Ignore("fails because of Bug #1234") .

In questo modo, il test è lì, ma la build non si interrompe.

Ovviamente si nota il test ignorato nel bug db, quindi il @Ignore viene rimosso una volta che il test è stato corretto. Questo serve anche come un facile controllo per la correzione di bug.

Il punto di rottura della build sui test falliti non è quello di mettere la squadra sotto pressione - è per avvisarli di un problema. Una volta che il problema è stato identificato e archiviato nel DB degli errori, non ha senso eseguire il test per ogni build: sai che non funzionerà.

Ovviamente, il bug dovrebbe ancora essere corretto. Ma pianificare la correzione è una decisione aziendale, e quindi non è proprio la preoccupazione dello sviluppatore ... Per me, una volta che un bug è archiviato nel bug DB, non è più un mio problema, finché il proprietario del prodotto / del prodotto non mi dice che lo vogliono fisso .

Why would you want to allow a build to succeed with known defects?

Perché a volte hai dei limiti di tempo. O il bug è così piccolo che non vale davvero la pena di ritardare la spedizione del prodotto per alcuni giorni necessari per testare l'unità e risolverlo.

Inoltre, qual è il punto nel rompere intenzionalmente la build ogni volta che trovi un bug? Se lo hai trovato, aggiustalo (o assegnalo alla persona che lo risolverà), senza disturbare tutta la tua squadra. Se vuoi ricordare di correggere un bug, devi contrassegnarlo come molto importante nel tuo sistema di tracciamento dei bug.

I test sono lì per assicurarti di non (ri) introdurre problemi. L'elenco dei test non validi non sostituisce un sistema di tracciamento dei bug. C'è una certa validità nel POV che i test non riusciti non sono solo indicazioni di bug, ma sono anche un'indicazione del fallimento del processo di sviluppo (dalla negligenza alla dipendenza mal identificata).

"Interrompi la build" significa per impedire che una compilazione abbia esito positivo . Un test fallito non lo fa. È un'indicazione che la build ha difetti conosciuti, che è esattamente corretta.

La maggior parte dei server di build monitora lo stato dei test nel tempo e assegnerà una classificazione diversa a un test che ha fallito da quando è stato aggiunto a una regressione (test che passava e non funziona più) e rileva anche la revisione in cui è avvenuta la regressione.

Direi che il test fallito dovrebbe essere aggiunto, ma non esplicitamente come "un test fallito".

Come @BenVoigt sottolinea in la sua risposta , un test fallito non necessariamente "rompe la build. " Immagino che la terminologia possa variare da squadra a squadra, ma il codice continua a essere compilato e il prodotto può ancora essere spedito con un test non funzionante.

Ciò che dovresti porci in questa situazione è,

What are the tests meant to accomplish?

Se i test servono solo a far sentire tutti a proprio agio sul codice, quindi aggiungere un test non funzionante solo per far sentire male a tutti il codice non sembra produttivo. Ma poi, quanto sono produttivi i test, in primo luogo?

La mia affermazione è che i test dovrebbero riflettere i requisiti aziendali . Quindi, se è stato trovato un "bug" che indica che un requisito non è stato soddisfatto, allora è anche un'indicazione che i test non rispecchiano in modo appropriato o completo i requisiti aziendali.

Che è il bug da correggere per primo. Non stai "aggiungendo un test negativo". stai correggendo i test per riflettere in modo più accurato i requisiti aziendali. Se il codice non riesce a superare quei test, questa è una buona cosa. Significa che i test stanno facendo il loro lavoro.

La priorità della correzione del codice è determinata dall'azienda. Ma fino a quando i test non saranno risolti, questa priorità potrà davvero essere determinata? L'azienda dovrebbe essere armata con la conoscenza di esattamente ciò che sta fallendo, come sta fallendo, e perché sta fallendo al fine di prendere le proprie decisioni in via prioritaria. I test dovrebbero indicarlo.

Avere test che non superano completamente non è una cosa negativa. Crea un grande artefatto di problemi noti che deve essere definito come prioritario e gestito di conseguenza. Avere test che non completamente test , tuttavia, è un problema. Mette in discussione il valore dei test stessi.

Per dirlo in un altro modo ... La build è già rotta. Tutto quello che decidi è se richiamare o meno l'attenzione su questo fatto.

Nel nostro team di automazione dei test, controlliamo i test non riuscendo finché falliscono a causa di un difetto nel prodotto piuttosto che un difetto nel test. In questo modo abbiamo prove per la squadra di sviluppo che hey, l'hanno rotto. Rompere la build è molto disapprovato, ma non è la stessa cosa che controllare i test perfettamente compilabili ma falliti.

Scrivere un test che sai non funzionerà fino a quando il bug non verrà risolto è una buona idea, è la base di TDD.

Rompere la costruzione è una cattiva idea. Perché? Perché significa che nulla può andare avanti finché non viene risolto. In pratica blocca tutti gli altri aspetti dello sviluppo.

Esempio 1
Cosa succede se la tua applicazione è di dimensioni variabili, con molti componenti? Cosa accadrebbe se quei componenti venissero lavorati da altri team con il loro ciclo di rilascio? Difficile! Devono attendere la correzione del bug!

Esempio 2
Cosa succede se il primo bug è difficile da risolvere e trovi un bug un altro con una priorità più alta? Rompi anche la build per il secondo bug? Ora non puoi costruire finché entrambi sono corretti. Hai creato una dipendenza artificiale.

Non esiste una ragione logica per cui il fallimento di un test dovrebbe interrompere una build. Questa è una decisione che il team di sviluppo deve fare (magari con una discussione gestionale) che soppesa i pro ei contro del rilascio di una build con bug noti. Questo è molto comune nello sviluppo di software, praticamente tutti i principali software sono rilasciati con almeno alcuni problemi noti.

Dipende dal ruolo che i test dovrebbero svolgere e da come i loro risultati dovrebbero influenzare il sistema di costruzione / processo adottato. La mia comprensione della rottura della build è la stessa di quella di Ben, e allo stesso tempo non dovremmo controllare consapevolmente il codice che interrompe i test esistenti. Se quei test sono arrivati "più tardi", potrebbe essere "okay" ignorarli solo per renderli meno inutilmente distruttivi per gli altri, ma trovo questa pratica di ignorare i test falliti (in modo che sembrino passare) piuttosto inquietanti (specialmente così per le unit test), a meno che non ci sia un modo per indicare tali test come né rosso né verde.

Dipende dal bug, ovviamente, ma generalmente se qualcosa è andato storto che non è stato identificato durante i test manuali o automatizzati, allora ciò implica che c'è una lacuna nella copertura. Sicuramente incoraggerei a capire la causa principale e a schiaffeggiare un caso di test unitario in cima al problema.

Se si tratta di un problema di produzione pianificato per una correzione rapida da un ramo di manutenzione, è inoltre necessario assicurarsi che la correzione funzioni sulla linea principale e che uno sviluppatore non possa respingere erroneamente la correzione con un over-zealous unire la risoluzione del conflitto.

Inoltre, in base alla politica di rilascio, la presenza di test unitari appena aggiornati può aiutare a confermare che uno sviluppatore ha effettivamente risolto il problema, piuttosto che semplicemente modificarlo [(il problema oi test?)], sebbene ciò dipenda da avendo codificato i requisiti corretti nei test delle nuove unità.

Un problema con l'aggiunta di un test "know-to-fail" alla build è che il tuo team potrebbe avere l'abitudine di ignorare i test non riusciti perché si aspetta che la compilazione fallisca. Dipende dal tuo sistema di build, ma se un test fallito non significa sempre "qualcosa si è appena rotto", allora è facile prestare meno attenzione ai test falliti.

Non vuoi aiutare la tua squadra a entrare in quella mentalità.

Quindi sono d'accordo con sleske che dovresti aggiungi il test, ma contrassegnalo come" ignorato " ai fini della compilazione automatica, finché il bug non viene corretto.

Anche se penso che dovresti in qualche modo 'controllare' il bug come test, in modo che quando lo aggiusti non succeda più, e in qualche modo lo assegni a priorità, penso che sia meglio non rompere la build (/ i test). La ragione è che successivamente i commit di rottura del build saranno nascosti dietro il tuo test rotto. Quindi, verificando un test errato per questo bug, si richiede che l'intera squadra metta da parte il proprio lavoro per correggere questo bug. Se ciò non dovesse accadere, potresti finire con dei commit che non sono tracciabili come tali.

Quindi direi che è meglio impegnarlo come test in sospeso, e renderlo una priorità nella tua squadra di non avere test in sospeso.

Un'altra opzione è quella di verificare il test non funzionante in un ramo separato nel sistema di controllo del codice sorgente. A seconda delle tue pratiche, ciò potrebbe essere possibile o meno. A volte apriamo una nuova filiale per lavori in corso, come la correzione di un bug che non è banale.