Il codice duplicato è un odore nel codice di unit test tanto quanto in un altro codice. Se hai codice duplicato nei test, diventa più difficile refactoring del codice di implementazione perché hai un numero sproporzionato di test da aggiornare. I test dovrebbero aiutarti a eseguire il refactoring con sicurezza, piuttosto che essere un grande fardello che ostacola il tuo lavoro sul codice da testare.
Se la duplicazione è in fixture impostata, considerare un maggiore utilizzo del setUp
metodo o fornire più (o più flessibile) Creazione Metodi .
Se la duplicazione è nel codice che manipola il SUT, chiediti perché più cosiddetti test "unitari" stanno esercitando la stessa identica funzionalità.
Se la duplicazione è nelle asserzioni, forse hai bisogno di alcune asserzioni personalizzate . Ad esempio, se più test hanno una stringa di asserzioni come:
assertEqual('Joe', person.getFirstName())
assertEqual('Bloggs', person.getLastName())
assertEqual(23, person.getAge())
Allora forse hai bisogno di un unico assertPersonEqual
metodo, in modo da poter scrivere assertPersonEqual(Person('Joe', 'Bloggs', 23), person)
. (O forse hai semplicemente bisogno di sovraccaricare l'operatore di uguaglianza su Person
.)
Come hai detto, è importante che il codice di test sia leggibile. In particolare, è importante che l' intento di un test sia chiaro. Trovo che se molti test sembrano per lo più uguali (ad esempio tre quarti delle linee uguali o praticamente uguali) è difficile individuare e riconoscere le differenze significative senza leggerle e confrontarle attentamente. Quindi trovo che il refactoring per rimuovere la duplicazione aiuti la leggibilità, perché ogni riga di ogni metodo di test è direttamente pertinente allo scopo del test. È molto più utile per il lettore di una combinazione casuale di righe direttamente pertinenti e righe che sono solo standard.
Detto questo, a volte i test esercitano situazioni complesse simili ma comunque significativamente diverse, ed è difficile trovare un buon modo per ridurre la duplicazione. Usa il buon senso: se ritieni che i test siano leggibili e chiarisci il loro intento, e ti senti a tuo agio nel dover forse aggiornare più di un numero teoricamente minimo di test durante il refactoring del codice invocato dai test, accetta l'imperfezione e spostati a qualcosa di più produttivo. Puoi sempre tornare indietro e rifattorizzare i test più tardi, quando l'ispirazione colpisce!