Come faccio a fare TDD quando il comportamento previsto deve essere cambiato?

7

Ho fatto TDD con un progetto a cui sto lavorando e ho un numero piuttosto elevato di test. Ho parecchi test automatici sulle restrizioni applicate nel codice, assicurandomi che le cose che non dovrebbero essere permesse non sono permesse. Ora mi è stato detto che a causa di cambiamenti nel nostro modello di licenza, alcune di queste restrizioni devono essere rimosse.

Da quando ho fatto l'intero progetto usando TDD, non sono sicuro di come fare una modifica come questa usando anche la mentalità TDD.

Quindi la mia domanda è: apporto le modifiche al back-end e vedo quali test si interrompono, oppure cerco di trovare i test che rafforzano il comportamento e li modificano prima?

La mia preoccupazione è che se ci sono operazioni A, B, C e D in cui viene effettuato un controllo per non consentire il comportamento, e ho test equivalenti TestA, TestB, TestC e TestD (possibilmente in luoghi diversi), indipendentemente da quale Mezzo I cambia per primo, potrei perdere uno o due punti e finire con un comportamento scorretto, ma ho ancora superato tutti i test (es. cosa succede se mi manca TestD?)

    
posta Shawn D. 28.10.2011 - 00:41
fonte

4 risposte

12

Avendo fatto l'intero progetto con TDD, ti consiglierei di seguirlo. Molti requisiti stanno cambiando, ma prendili uno alla volta. Per un nuovo requisito, scrivici un test o trova il test esistente che ora dovrebbe avere risultati diversi. Cambialo per corrispondere al nuovo requisito e guardalo diventare rosso. Ora fallo passare. Quando lo fai passare, potresti trovare altre interruzioni di test (o test), perché quel test dipendeva dal vecchio comportamento. Va bene. Rivedi il test di rottura e assicurati di non avere un comportamento veramente rotto (se hai, annulla la tua modifica). Aggiorna il test di rottura per corrispondere al nuovo comportamento desiderato e guardalo diventare verde. Ripeti fino al completamento.

    
risposta data 28.10.2011 - 00:54
fonte
5

Idealmente, trova i test che rafforzano il comportamento e cambia quelli prima. In questo modo puoi vedere il test fallito prima di farlo passare di nuovo, il che è perfetto TDD.

Se ti manca, allora così sia. Il pragmatismo di solito entra in azione e basta correggere il test.

Se fossi veramente pedante, dovresti essere in grado di cambiare il codice, cambiare quel test, vederli fallire tutti e poi ripararlo di nuovo. Sono abbastanza severo con me stesso su TDD e anche io non sono così pedante. Non penso che questo passo offra molto.

    
risposta data 28.10.2011 - 00:55
fonte
0

Il modo usuale per affrontare questo è introdurre un flag e modificare il comportamento del codice di test e di produzione in base al flag. Ad esempio, se si introducono acquisti self-service di vaniglia frappes, il codice di test controlla il flag HAVE_AUTO_FRAPPE e assertTrue () o assertFalse () a seconda di esso. Questo ha il vantaggio che devi apportare la modifica alla tua suite di test e al codice di produzione solo una volta. Quando la modifica ha effetto, basta capovolgere il bit e nient'altro. (Ovviamente puoi rimuovere l'intero meccanismo in un secondo momento se sicuramente non cambierà, ad es. Quando esegui il refactoring per chiarezza, ma non devi.)

    
risposta data 28.10.2011 - 09:01
fonte
0

Con TDD, per definizione è necessario modificare i test per riflettere i nuovi comportamenti e quindi modificare il codice fino a quando non passano tutti i test. Tuttavia, a seconda delle dimensioni del tuo codice base e della quantità di tempo che tu (e il tuo team) avete assegnato per completare questa transizione, potrebbe non esserci abbastanza tempo per farlo in quel modo. Potrebbe essere necessario selezionare alcune sezioni chiave, aggiornare i test e quindi il codice e inserire gradualmente le modifiche.

    
risposta data 28.10.2011 - 20:33
fonte

Leggi altre domande sui tag