Clearing some misunderstandings about TDD
Great post:
http://codebetter.com/iancooper/2011/10/06/avoid-testing-implementation-details-test-behaviours
Re-reading Kent Beck’s TDD book, Ian Cooper recovers some important things that are often overlooked.
October 10th, 2011 at 12:03
In sostanza fare TDD nel modo giusto significa fare design durante la fase di refactoring.
Immagino che un mostro dell’OOP possa essere in grado di fare solo così, ma ho qualche dubbio.
Come si concilia una fase di analisi e design precedente alla scrittura del codice con questo?
Mi verrebbe da dire che l’approccio corretto (per lo meno è quello che nel mio caso sembra dare frutti) è quello di fare una prima analisi/design, poi partire col primo test rimanendo su questa traccia e non facendo la prima porcheria che viene in mente.
La fase di refactoring consente poi di affinare le cose e spesso evidenziare problemi o soluzioni alternative.
E’ questa la lezione o c’è dell’altro?
October 10th, 2011 at 22:58
Il design inizia già quando scrivi il test….
October 12th, 2011 at 09:39
Si, la mia osservazione è: secondo me comincia ancora prima, prosegue col primo test e poi col refactoring.
Quello che mi chiedo è: è possibile (c’è chi lo fa?) eliminare il design pre-test, è ragionevole? Oppure è una pretesa che deriva da un fraintendimento?
October 12th, 2011 at 11:21
Sì è possibile. Si tratta di partire a risolvere una fetta verticale molto sottile del tuo problema e poi essere *molto* convinti nel rimuovere la duplicazione (cioè cercare il design) ad ogni passo. Rimuovere la duplicazione con l’intento di fare emergere esplicitamente le intenzioni, ovvero i concetti di business del tuo problema. Bisogna seguire le regole di Kent Beck:
Passa tutti i test
Senza duplicazione
Esprime tutti i concetti che dobbiamo esprimere
Con il minimo numero di classi e metodi
In quest’ordine. E’ una tecnica… che presuppone comunque una forte conoscenza di concetti di design da parte degli sviluppatori.