Devo refactificare i test delle mie unità quando estraggo una classe dal System Under Test?

Ho scritto questa lezione che fa alcune cose (forse questa è una violazione del principio della responsabilità singola). Ora mi rendo conto che un'altra parte del progetto ha bisogno di un pezzo di quella logica e il modo in cui lo esporrò è quello di estrarre una classe dal mio originale System Under Test.

Prevedo di essere in grado di farlo senza dover modificare alcun codice di test, ma quando avrò finito, potresti obiettare che il test non è più un test unitario . Testerà la classe originale e la classe che ho estratto. In altre parole, avrò un caso di prova, ma due sistemi in prova.

Devo refactificare il mio codice di prova dopo aver finito? IE: creare un ExtractedClassTest e spostare tutti i test rilevanti da OriginalClassTest in esso? Sembra che potrebbe essere un po 'rischioso: potrei perdere un po' di copertura nel processo, potrebbe non essere semplice come spostare un test e finirei per riscrivere un codice di test che conosco funzionava ma che potrebbe non essere più, eccetera.

D'altra parte, se lascio OriginalClassTest così com'è, vedo che si tratta di un problema di manutenzione di prova. Sarà un po 'confuso scoprire dove si trovano i test di ExtractedClass. La tua prima impressione sarà che non esista. Nel tempo, con molte rifatturazioni del codice di produzione, questo potrebbe diventare un problema serio.

Sono nuovo di TDD, quindi vorrei il parere di un esperto. Grazie!

Dopo aver visto questo fantastico discorso "Ian Cooper: TDD, dove è andato tutto storto", non sarò d'accordo con @pdr. Penso che dovresti mantenere solo i test originali. La tua capacità di riformattare il tuo sistema sotto test senza interrompere, scrivere o modificare alcun test è in primo luogo lo scopo di scrivere test.

Se dovessi testare la classe estratta, testerei l'implementazione piuttosto che il comportamento. Di conseguenza, il mio codice sarebbe più difficile da refactificare in futuro: questi nuovi test probabilmente fallirebbero anche se il comportamento continuasse a funzionare.

Per la durata dello sviluppo, avere entrambi. Mantieni i vecchi test come garanzia di non aver rotto nulla, scrivi nuovi test (da zero) per aiutarti a progettare le classi come dovrebbero essere.

Alla fine, esegui e rimuovi tutto ciò che è defunto nei vecchi test. Stai attento in questa analisi; non rimuovere qualcosa perché pensi che dovrebbe essere defunto. Dimostrare a te stesso (o qualcun altro o un'anatra di gomma) perché non è più necessario. Rompere il test e assicurarsi che un altro test si interrompa con esso.

Tutto ciò che rimane nei vecchi test dovrebbe essere preso caso per caso, ma per lo più dovrebbero essere riscritti nella nuova struttura.

Perché hai ragione, non vuoi lasciarti andare a un incubo di manutenzione. Ma non vuoi meno copertura del percorso rispetto a prima.