Quando si modifica una classe / un metodo e si hanno già test delle unità che passano, dovresti cambiare, testare o scrivere un test, quindi cambiare?

Question

Quando si modifica una classe / un metodo e si hanno già test delle unità che passano, dovresti cambiare, testare o scrivere un test, quindi cambiare?

#1 da (9 voti)
#2 da (1 voti)

2

Dire che ho una classe con un singolo costruttore che accetta 2 parametri e inizializza se stessa usando quei parametri. Ho scritto test per questo e stanno passando tutti.

In seguito mi rendo conto che è necessario apportare un'aggiunta al costruttore per accettare tre parametri. Dovrei

a) Aggiungi il nuovo parametro, guarda i miei test interrotti e prova a risolverlo

b) Riscrivi i test esistenti per testare il nuovo comportamento previsto, guardali inizialmente non riuscire e quindi aggiungi alla classe (questo per me sembra un modo più TDD)

Da un punto di vista TDD, penso che l'opzione "b" abbia più senso. Tuttavia, l'opzione 'a' (per me) sembra un approccio più naturale.

C'è un modo standard in cui la maggior parte delle persone fa questo?

tdd unit-testing

posta BenM 28.02.2014 - 11:13

fonte

2 risposte

1

Suppongo che ciò che è più naturale dipende dal fatto che tu sia uno sviluppatore guidato da test o un ultimo sviluppatore di test.

Citando "Software orientato agli oggetti in crescita, guidato da test" (Steve Freeman, Nat Pryce), la regola d'oro di TDD è: Non scrivere mai nuove funzionalità senza un test non valido.

risposta data 04.03.2014 - 13:22

fonte

Leggi altre domande sui tag tdd unit-testing

Entrate greenfield vs. brownfield? (tentando di ottenere un'idea di misura dello sforzo speso sui due) L'inversione di dipendenza è sempre migliore?

score 9 · Accepted Answer

Ovviamente, TDD dice che dovresti fare (b).

Le modifiche alle firme dei metodi pongono la complicazione che in molte lingue i test non falliranno effettivamente - non verranno nemmeno compilati! È una questione di opinione se questo costituisce un test "in errore" per il quale, secondo il tipo più rigido di TDD, è consentito scrivere un nuovo codice.

Ma il punto di TDD è proprio controllare che la tua API abbia senso prima programmarla. Se devi modificare molti test per aggiungere un parametro, potresti notare che questo è ingombrante, che sarebbe meglio creare un oggetto composto per alcuni di questi parametri, o che devi essere in grado di creare oggetti senza il nuovo parametro, dopo tutto! Questo è il valore reale di TDD (al contrario di garantire semplicemente la copertura del test), e questo è perché direi di andare avanti e rivedere prima i test.