TDD: le regole dello zio Bob rispetto al ciclo classico

Robert C. Martin 'The Clean Coder', chapter 5 'Test Driven Development'

Per quel che vale, vedrai le stesse regole sul suo sito web: Tre regole del TDD .

Where is the place for refactoring?

Accade su una cadenza diversa. Vedi I cicli di TDD .

Second-by-Second nano-cycle: The Three Laws of TDD.

the goal is always to promote the line by line granularity that I experienced while working with Kent so long ago."

vs.

Minute-by-Minute: micro-cycle: Red-Green-Refactor

This cycle is typically executed once for every complete unit test, or once every dozen or so cycles of the three laws. The rules of this cycle are simple.

• Create a unit tests that fails
• Write production code that makes that test pass.
• Clean up the mess you just made.

Per un confronto, considera come Kent Beck ha descritto TDD in Sviluppo guidato da test .

1. Quickly add a test
2. Run all tests and see the new one fail
3. Make a little change
4. Run all tests and see them all succeed
5. Refactor to remove duplication

In altre parole, ciò che Beck descrive è il flusso di lavoro Red-Green-Refactor - scrivi l'intero test. Questo introduce un sacco di errori del compilatore (perché gli esempi in quei giorni erano scritti in Java). Scrivi un po 'di codice per correggere ogni errore a turno. Ora hai un test fallito (ROSSO). Scrivi un po 'di codice in più per far passare il test. Ora hai un'implementazione che soddisfa tutti i tuoi test (VERDE). Ora ripulisci il pasticcio (REFATTORE).

Ciò che le tre leggi di TDD ti danno è un nano flusso di lavoro entro ROSSO-VERDE. Esegui il tick-tock tra la scrittura del codice di prova e la scrittura del codice di produzione, correggendo ogni errore così com'è, fino a quando l'implementazione non fornisce il comportamento corretto.

Da quello che posso dire, dove spicca il nanociclo è in quei posti dove si sta estendendo il sistema sotto test; aggiungendo un nuovo metodo o una nuova classe. Questi sono i casi in cui si vedono errori del compilatore che devono essere corretti. Nel caso in cui si stia creando un test per valutare un comportamento modificato, c'è poco da distinguere tra il nanociclo e la calibrazione del test.

Queste sono le regole per TDD. Il refactoring avviene quando si hanno test verdi e non si aggiungono test e / o codice di produzione. I.e dopo 3. e prima del prossimo round di 1.

Nel ciclo classico, queste tre regole descrivono le parti "Rosso" (1, 2) e "Verde" (1, 3) del ciclo.

Penso che manchi una regola implicita:

• È consentito il refactoring del codice di produzione che si trova in un test esistente, a condizione che non cambi assolutamente alcun comportamento.

Perché è questo che è il refactoring. 2 * 4 è lo stesso di 4 * 2. Quindi lo stesso test per 8 funziona su entrambi.

Se stai assumendo che non puoi farlo, perché dici che vuoi che il test diventi rosso, ricorda che fallire la compilazione è un test rosso. Tutto quello che devi fare per diventare rosso è iniziare a digitare.

Questa idea è importante perché se gli alieni improvvisamente ti rapiscono, tua moglie chiama dicendo che il bambino sta arrivando adesso, o che l'edificio prende fuoco, è bello se sei pronto. Vuoi che il tuo codice urlizzi chiaramente i problemi quando torni al lavoro. Non vuoi che il tuo codice sia mai in uno stato in cui le cose vanno bene quando non lo sono.

Devi aggiungere un nuovo test quando ti stai preparando a scrivere una trasformazione che cambierà il comportamento. Non confondere questi due diversi tipi di modifiche.

Potrebbe anche valere la pena notare che a volte test hanno bisogno di refactoring stessi .

Mentre TDD e molte delle "regole" intorno a esso sono buone, sono in gran parte scritte da programmatori che hanno difficoltà a esprimersi chiaramente in inglese. In questo caso, lo zio Bob non stava suggerendo solo di farlo, era frustrato dal fatto che le persone non avessero nemmeno ottenuto questa piccola parte del processo.

Il mio consiglio, segui il ciclo PDSA e ascolta alcune presentazioni di Kevlin Henney su YouTube. Cerca in particolare uno chiamato "GUTS".

Per riassumere:

• Pianifica cosa realizzerai scrivendo un test. Deve correre, deve fallire, deve indicare chiaramente ciò che verrà raggiunto. Invece di scrivere un nuovo test, potrebbe essere necessario modificare un test. Se si sta eliminando un test, sostituirlo con la sua negazione (il sistema non eseguirà più X).
• Sviluppa il codice per far passare tutti i test.
• Studia ciò che hai raggiunto. Guardalo e vedi cosa potrebbe essere migliorato, reso più semplice ecc. Nessuna codifica durante questo passaggio . Guarda, pensa, discuti e impara.

• Agisci su ciò che hai appreso apportando piccoli miglioramenti, aggiungendo attività al tuo backlog o migliorando il modo in cui codifichi in futuro.

• Ripeti.