Devo scrivere un test per dimostrare che l'eliminazione del codice risolve un bug?

Di tanto in tanto mi imbatto nella situazione in cui la correzione di un bug richiede che elimini una sezione di codice. Il purista TDD sarebbe (presumo) sostenendo la scrittura di un test non riuscito, l'eliminazione del codice e quindi il superamento del test.

Ora, sembra davvero strano avere un test che asserisce che un po 'di codice è stato rimosso. Certo, suppongo che assicurerebbe che nessuno abbia scavato nel controllo del codice sorgente e reinserito quel codice, ma ne vale la pena? Se ne vale la pena, sembra sicuramente meno prezioso che scrivere un test per il codice che è stato aggiunto , giusto?

unit-testing tdd bug

— jhewlett
fonte

Penso che qualsiasi test di regressione sia utile, indipendentemente da come è stato corretto il bug

— Ismail Badawi,

Il test non afferma che il codice è stato rimosso - il test afferma che il bug è stato corretto ...

— user253751

Lo stai guardando nel modo sbagliato. Il test non afferma che il codice è stato rimosso. Il test fa affermare una certa funzionalità.

Il test non si preoccupa della quantità di codice richiesta per farlo passare, né si rende conto di aver rimosso del codice. Il valore di avere un tale test è lo stesso di qualsiasi altro test che crei a causa di un bug: hai fiducia nell'assenza del bug quando il test passa e l'integrazione del test nel processo di compilazione ti assicura che il bug molto probabilmente non verrà reintrodotto.

Un altro modo per vederlo da una prospettiva TDD è il seguente: Quando sai che l'eliminazione del codice corregge il bug e ti chiedi quindi se scrivere un test, hai già sbagliato TDD. Una volta che inizi a lavorare sul bug, dovresti prima scrivere il test che assicuri la presenza del bug fallendo. Solo in seguito si corregge il bug effettivo, che può richiedere la rimozione del codice o meno, e si passa al test. La domanda che stai ponendo non si pone nemmeno in quel modo.

— Franco
fonte

+1, ma posso immaginare la seguente situazione: il codice rimosso conteneva alcune assurde funzionalità aggiunte da qualcuno che non comprendevano correttamente il dominio problematico. Ora, durante una revisione del codice, un altro sviluppatore vede che l'intera parte è davvero senza senso e il codice verrà rimosso. Avere molti test per tali comportamenti senza senso può gonfiare la tua suite di test.

— Doc Brown,

Chiaramente la funzionalità rimossa ha gestito in modo errato alcuni input / output. Chiaramente qualcuno in seguito potrebbe fraintendere il problema allo stesso modo. Se temi che la suite di test si gonfi, non penso che TDD sia adatto a te. Qual è comunque l'abito da prova gonfio?

— Dorus,

@DocBrown: se stanno facendo TDD, allora ci deve essere un test che richiede quella funzionalità assurda, altrimenti non avrebbero nemmeno potuto scrivere quel codice in primo luogo! Ricorda, ti è permesso solo scrivere la quantità minima assoluta di codice per far passare il test. Se non esiste un test del genere, il codice non dovrebbe mai essere stato scritto in primo luogo e può essere semplicemente eliminato. Se c'è una prova che le forze che il comportamento assurdo, allora quel test dovrebbero essere rimossi, e ora siamo allo stesso caso che ho descritto prima: il test è andato, eliminare il codice.

— Jörg W Mittag,

In entrambi i casi, non aggiungi mai alcun test alla suite di test e nel secondo caso ne rimuovi persino uno. Tuttavia, se si scopre che il test ha davvero senso, beh, allora la funzionalità non era così assurda dopo tutto.

— Jörg W Mittag,