Si consigliano test post-hoc in TDD?

Ogni volta che vuoi modificare un'area non testata, riscrivi i test per la piccola area che stai modificando e poi apporta le tue modifiche.

Questo ti permetterà di riscoprire / specificare il vecchio codice.

Finché i vecchi test sono andati bene e le regole aziendali che coprono sono ancora valide, allora vale la pena rivisitare. Speriamo che ci voglia solo qualche modifica a quei test. La cosa più importante è che tutte le regole aziendali sono coperte dai test, se le regole aziendali sono considerate "vecchie" o "nuove".

Sfortunatamente, tornare indietro e fare questo in massa ci vorrà un po 'di tempo. Ma alla fine ne varrà la pena. Perché alla fine il numero di bug rilevati dovrebbe essere molto inferiore. Spero che tu non cada di nuovo in questa stessa fossa. Un sacco di persone che fanno TDD tendono a saltare i test di fissazione quando sono in crisi o ci sono grandi cambiamenti. Ma penso che sia più controproducente, perché non si è sicuri di quali saranno gli effetti della modifica di un particolare modulo e si potrebbero finire con ancora più bug. I test dovrebbero essere trattati come un altro consumatore del codice e dovrebbero essere trattati nella stessa categoria, come ad esempio l'interfaccia utente.

Personalmente ritengo che dovresti trattare questa situazione come se il vecchio codice fosse "legacy" (come nel libro di Feathers "Working with Legacy Code") e andare avanti da quel punto.

Significa che ridisegna tutte le parti "solidificate" ma non testate, una alla volta, prima i test. Forse alcune parti diventano nuove. più semplice, implementazione, forse non del tutto in quanto quella esistente va bene.

Ma è solo una sensazione, non ero ancora in una situazione simile.