Devo rifattorizzare i miei test unitari quando estraggo una classe dal sistema in prova?

13

Ho scritto questa lezione che fa alcune cose (forse questa è una violazione del Principio di Responsabilità Unica). Mi rendo conto ora che un'altra parte del progetto ha bisogno di un pezzo di quella logica e il modo in cui esporrò è quello di estrarre una classe dal mio sistema originale sotto test.

Prevedo di poterlo fare senza dover modificare alcun codice di test, ma al termine potrei sostenere che il test non è più un test unit . Verranno testati la classe originale e la classe che ho estratto. In altre parole, avrò un caso di test, ma due sistemi sotto test.

Dovrei rifattorizzare il mio codice di test dopo che ho 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 so che funzionava ma che non è più possibile, ecc.

D'altro canto, se esco da OriginalClassTest così com'è, posso vedere che si tratta di un problema di manutenzione del test. Sarà un po 'di confusione scoprire dove sono i test di ExtractedClass. La tua prima impressione sarà che non esiste. Con il passare del tempo con molti refactoring del codice di produzione, questo potrebbe diventare un problema serio.

Sono nuovo di TDD quindi mi piacerebbe un consiglio di un esperto. Grazie!

    
posta Daniel Kaplan 09.02.2013 - 01:10
fonte

2 risposte

7

Dopo aver guardato questo fantastico discorso "Ian Cooper: TDD, dove è andato tutto storto", non sono d'accordo con @ pdr. Penso che dovresti mantenere solo i test originali. La capacità di refactoring del sistema in prova senza rompere, scrivere o modificare alcun test è l'unico scopo di scrivere test in primo luogo.

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

    
risposta data 26.03.2014 - 18:02
fonte
6

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

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

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

Perché hai ragione, non vuoi rimanere con un incubo di manutenzione. Ma non vuoi una copertura del percorso inferiore a quella che avevi prima.

    
risposta data 09.02.2013 - 01:17
fonte