Dovremmo sempre unitare i bug di test quando li correggiamo?

Sì, in generale si dovrebbe . Come per tutte le linee guida, dovrai usare il tuo miglior giudizio quando si scontrano con altre linee guida. Per questo scenario, la gravità del bug deve essere valutata rispetto al lavoro necessario per implementare il test e la qualità di quel test in modo mirato al problema aziendale e alla cattura della regressione dello stato del bug.

Tenderei a preferire i test di scrittura su no, dal momento che le interruzioni di esecuzione di bug tendono ad avere un sovraccarico maggiore rispetto al semplice sviluppo e mantenimento di un test unitario.

Penso che la migliore pratica, una che sono imbarazzato nell'ammettere che non seguo spesso, è quella di creare un sistema o test di integrazione che dimostri il problema osservato in produzione, quindi cercare di trovare le unità responsabili per il problema, e quindi scrivi i test unitari per quelle unità che dimostrano il problema a livello di unità . Una volta che hai i test unitari, correggi le unità ed esegui tutti i test. A questo punto, può essere prudente scartare il test originale - perché potrebbe essere fragile e / o lento - ma mantenere i test unitari nella tua suite automatizzata a scopo di regressione e copertura.

La pratica di scrivere un test per identificare il difetto è una buona idea, poiché consente di identificare esattamente quali passaggi sono necessari per riprodurre il difetto e verificare che sia stato corretto. Inoltre, questi test possono essere eseguiti come parte di test sul fumo o test di regressione per garantire che le modifiche successive non abbiano reintrodotto un vecchio difetto nel sistema.

La prima cosa da considerare è il livello del test necessario. Forse il test per verificare la correzione sarebbe più appropriato a livello di sistema, o forse anche un test di accettazione eseguito manualmente. Penso che sia più importante avere un test documentato e gestito, indipendentemente da come è stato implementato in modo specifico.

Per quanto riguarda il modo in cui il refactoring influisce sui test, dipende dalle caratteristiche specifiche. In alcuni casi, il refactoring (o qualsiasi tipo di lavoro, come le nuove funzionalità) potrebbe rendere i test non più necessari. Il problema, come originariamente accaduto, potrebbe non essere più possibile. In tal caso, potrebbe essere saggio rimuovere il test dai test possibili per rendere il processo di test (automatico o manuale) più snello. In altri casi, ci sono più metodi per eseguire il test e la verifica della funzione a un livello diverso potrebbe essere più appropriata. Se la funzione è minore, forse il test non è più necessario affatto.

Puoi anche considerare non solo affidarti ai test, ma anche al logging. Ad esempio, l'acquisizione di informazioni in fase di esecuzione (con diversi livelli di verbosità a seconda dell'ambiente, più prolisso durante il test, meno prolisso durante la distribuzione), profilazione dell'applicazione, acquisizione di dump dello stato corrente del sistema. Se riesci a trovare i trigger comuni al problema, puoi utilizzarlo per guidare il test a tutti i livelli.

Sì, dovresti.

Scrivi test unitari per la base di codice esistente. Quando correggi un bug, devi assicurarti che il tuo test dell'unità fallisca - questo ti darà la certezza che stai lavorando su un bug. È quindi necessario ri-fattore e fare passare il test risolvendo il bug.

Questa non è una pratica TDD. Nei test TDD guidi il tuo design, ma nel tuo caso il design è già stato deciso.