Test Driven Development quando cambiano le specifiche

Question

Test Driven Development quando cambiano le specifiche

#1 da (10 voti)
#2 da (3 voti)

4

In questi giorni, è abbastanza comune per me essere incaricato di apportare una modifica che in realtà infrange le specifiche precedenti. So che una delle idee principali alla base di TDD è di avere una suite che verifica che tutte le tue modifiche non abbiano effettivamente infranto nulla, ma che cosa fai quando il cambiamento è necessario, per sua natura, in realtà deve rompere il test unitario ?

Come fare lo sviluppo guidato da test è una domanda simile, ma è sottilmente diversa dalla mia domanda. Nel mio caso, ho già il test e le specifiche sono cambiate. In questa domanda, l'OP non ha ancora il test.

tdd unit-testing development-process

posta durron597 18.12.2014 - 22:15

fonte

2 risposte

Leggi altre domande sui tag tdd unit-testing development-process

Un test unitario utilizza il codice di installazione e un test di integrazione? Design basato sul dominio, due aggregati possono avere la stessa radice?

score 10 · Answer 1

Il ciclo pubblicizzato di TDD è test di scrittura fino a quando non falliscono, quindi esegui l'hacking del codice fino a quando non passano di nuovo e quindi refactoring mantenendo tutti i test che hanno avuto esito positivo.

Quando la specifica cambia, dovrai rimuovere i vecchi test che verificherebbero una violazione della nuova specifica e scriverà nuovi test che verificheranno la nuova specifica.

score 3 · Answer 2

TDD "del libro" ha un ciclo specifico e, specfialmente, per cambiare le specifiche, questo ciclo dovrebbe idealmente apparire come questo:

scrivi un test in base alle nuove specifiche (- > "red")
cambia il SUT ("subject under test") per abbinare il nuovo test; a seconda del cambiamento, questo potrebbe rompere alcuni vecchi test (- > il nuovo test diventa "verde", ma i vecchi test diventano "rossi")
Cambia i vecchi test se possono essere modificati per testare il SUT in base alle nuove specifiche. Oppure, se ciò non è possibile, eliminali (- > "verde")
ripeti dal punto 1 fino a quando non hai abbastanza test per convalidare l'intera specifica e il SUT lo implementa

Naturalmente, in uno scenario del mondo reale si cercherà di evitare situazioni in cui l'aggiunta di un test nel passaggio 1 comporterà l'eliminazione di 100 test esistenti nel passaggio 3. In questo caso, i test mostreranno che il tuo originale il design non era abbastanza evolutivo, oi tuoi test non erano abbastanza ASCIUTTI, o il cambiamento delle specifiche era così grande che in realtà dovevi abbandonare la maggior parte del SUT originale e scriverne uno nuovo.