Dovrei interrompere intenzionalmente la build quando viene rilevato un bug in produzione?

Mi sembra ragionevole che se un utente rileva un bug grave nella produzione, un test unitario non funzionante dovrebbe essere aggiunto per coprire quel bug, interrompendo così intenzionalmente la build fino a quando il bug non viene risolto. La mia logica per questo è che la build avrebbe dovuto fallire da sempre , ma non era dovuta a una copertura dei test automatizzata inadeguata.

Molti dei miei colleghi non sono d'accordo sul dire che un test unitario fallito non dovrebbe essere verificato. Sono d'accordo con questo punto di vista in termini di normali pratiche TDD, ma penso che i bug di produzione dovrebbero essere gestiti in modo diverso - dopo tutto perché dovresti voler consentire una build per avere successo con difetti noti?

Qualcun altro ha dimostrato strategie per gestire questo scenario? Capisco che rompere intenzionalmente la build potrebbe essere dannoso per gli altri membri del team, ma ciò dipende interamente da come stai usando le filiali.

La nostra strategia è:

Controlla un test fallito, 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 db bug, quindi @Ignoreviene rimosso una volta che il test è stato risolto. Questo serve anche come semplice controllo per la correzione dei bug.

Il punto di rompere la build in caso di test falliti non è in qualche modo mettere la squadra sotto pressione, ma avvisarli di un problema. Una volta che il problema è stato identificato e archiviato nel DB dei bug, non ha senso eseguire il test per ogni build: sai che fallirà.

Ovviamente, il bug dovrebbe essere comunque corretto. Ma programmare la correzione è una decisione commerciale, e quindi non è in realtà la preoccupazione del dev ... Per me, una volta che un bug è stato archiviato nel DB dei bug, non è più un mio problema, fino a quando il cliente / proprietario del prodotto non mi dice che lo vogliono corretto .

Perché dovresti consentire a una build di avere successo con difetti noti?

Perché a volte hai vincoli di tempo. Oppure 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 l'hai trovato, correggilo (o assegnalo alla persona che lo riparerà), senza disturbare tutta la tua squadra. Se si desidera ricordare di correggere un bug, è necessario contrassegnarlo come molto importante nel sistema di tracciamento dei bug.

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

"Break the build" significa impedire il completamento corretto di una build . Un test fallito non lo fa. Indica che la build presenta difetti noti, che è esattamente corretto.

La maggior parte dei server di build tiene traccia dello stato dei test nel tempo e assegnerà una classificazione diversa a un test che non ha funzionato da quando è stato aggiunto rispetto a una regressione (test che era solito superare e non funziona più) e rileva anche la revisione in cui il la regressione ebbe luogo.

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

Come sottolinea @BenVoigt nella sua risposta , un test fallito non "interrompe necessariamente la costruzione". 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 riuscito.

Quello che dovresti chiederti in questa situazione è,

Quali sono i test che si intende realizzare?

Se i test sono lì solo per far sentire tutti bene con il codice, quindi aggiungere un test fallito solo per far sentire tutti male con 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 . Pertanto, se viene trovato un "bug" che indica che un requisito non è soddisfatto in modo adeguato, significa anche che i test non riflettono correttamente o pienamente i requisiti aziendali.

Questo è il bug da correggere per primo. Non stai "aggiungendo un test non riuscito". Stai correggendo i test per riflettere meglio i requisiti aziendali. Se il codice non riesce a superare questi test, è una buona cosa. Significa che i test stanno facendo il loro lavoro.

La priorità di fissare il codice deve essere determinata dall'azienda. Ma fino a quando i test non saranno fissi, tale priorità può essere veramente determinata? Il business dovrebbe essere armato con la conoscenza di cosa sta esattamente fallendo, come sta fallendo e perché sta fallendo al fine di prendere le loro decisioni in via prioritaria. I test dovrebbero indicare questo.

Avere test che non superano del tutto non è una brutta cosa. Crea un grande manufatto di problemi noti che devono essere prioritari e gestiti di conseguenza. Avere test che non testano completamente , tuttavia, è un problema. Mette in discussione il valore dei test stessi.

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

Nel nostro team di automazione dei test, controlliamo i test non riusciti a condizione che falliscano a causa di un difetto nel prodotto piuttosto che di un difetto nel test. In questo modo abbiamo la prova per il team di sviluppo che ehi, hanno rotto. La rottura della build è fortemente disapprovata, ma non è la stessa cosa del check in test perfettamente compilabili ma falliti.

Scrivere un test che sai fallirà fino a quando il bug non sarà corretto è una buona idea, è la base di TDD.

Rompere la build è una cattiva idea. Perché? Perché significa che nulla può andare avanti fino a quando non viene risolto. In sostanza, blocca tutti gli altri aspetti dello sviluppo.

Esempio 1
Cosa succede se la tua applicazione è molto varia, con molti componenti? Cosa succede se quei componenti vengono elaborati da altri team con il proprio ciclo di rilascio? Difficile! Devono aspettare la tua correzione di bug!

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

Non esiste alcun motivo logico per cui il fallimento di un test dovrebbe interrompere una compilazione. Questa è una decisione che il team di sviluppo deve prendere (forse con una discussione di gestione) valutando i pro e i contro del rilascio di una build con bug noti. Questo è molto comune nello sviluppo del software, praticamente tutti i principali software vengono rilasciati con almeno alcuni problemi noti.

Dipende dal ruolo che dovrebbero svolgere i test e da come i loro risultati dovrebbero influenzare il sistema / processo di generazione adottato. La mia comprensione di infrangere la build è la stessa di Ben, e allo stesso tempo non dovremmo controllare consapevolmente il codice che rompe i test esistenti. Se questi test arrivassero "in seguito", potrebbe essere "ok" ignorarli solo per renderli meno inutilmente dannosi per gli altri, ma trovo questa pratica di ignorare i test falliti (in modo che sembrino passare) piuttosto inquietante (specialmente così per i test unitari), a meno che non esista un modo per indicare tali test come né rossi né verdi.

Dipende dal bug, ovviamente, ma in genere se qualcosa è andato storto e non è stato identificato durante i test manuali o automatici, ciò implica che c'è una lacuna nella copertura. Incoraggerei sicuramente a capire la causa principale e dare uno schiaffo a un caso di test unitario sul 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 eliminare erroneamente la correzione con una risoluzione del conflitto di unione troppo zelante .

Inoltre, a seconda della politica di rilascio, la presenza di test di unità appena aggiornati può aiutare a confermare che uno sviluppatore ha effettivamente risolto il problema, anziché semplicemente modificarlo [(il problema o i test?)], Sebbene ciò dipenda dal fatto di aver codificato il requisiti corretti nei nuovi test unitari.

Un problema con l'aggiunta di un test Know-to-Fail alla build è che il tuo team potrebbe prendere l'abitudine di ignorare i test non riusciti perché si aspettano che la build fallisca. Dipende dal tuo sistema di compilazione, ma se un test fallito non significa sempre "qualcosa si è appena rotto", è 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 aggiungere il test, ma contrassegnalo come 'ignorato' ai fini della compilazione automatica, fino a quando il bug non viene corretto.

Mentre penso che dovresti in qualche modo 'controllare' il bug come test, in modo che quando lo risolvi non accada di nuovo, e in qualche modo dare la priorità, penso che sia meglio non rompere la build (/ i test) . Il motivo è che i commit successivi verranno nascosti dietro il test interrotto. Quindi, controllando un test interrotto per questo errore, chiedi a tutto il team di mettere da parte il proprio lavoro per correggere questo errore. Se ciò non dovesse accadere, si potrebbe finire con il rompere i commit che non sono rintracciabili come tali.

Pertanto direi che è meglio impegnarlo come test in sospeso e renderlo una priorità per il tuo team non avere test in sospeso.

Un'altra opzione è quella di controllare il test fallito in un ramo separato nel sistema di controllo del codice sorgente. A seconda delle tue pratiche, questo può essere fattibile o no. A volte apriamo una nuova filiale per il lavoro in corso, come correggere un bug che non è banale.