Il coach del mio team xp di nome Nautilus
ci ha proposto un'interessante esercizio per mettere alla prova la qualità della nostra codebase.
Scrivere il test dello scenario che si vuole sviluppare come lo vorremmo, ignorando l'attuale architettura, misurando il tempo impiegato.
Provare poi a scriverlo usando i nostri oggetti misurando nuovamente il tempo impiegato.
Nel caso specifico la coppia, in quanto sviluppiamo in pair, ha impiegato 2 minuti a scrivere il test per il primo caso e tre
pomodori (circa un ora e mezza) nel secondo caso.
La differenza tra i due tempi indica quanto la nostra codebase è lontana dalla qualità che vorremmo ottenere.
Questa è l'essenza del TDD, cioè usare il test per comunicare come ci aspettiamo di utilizzare i nostri oggetti ed è anche
un indicatore di quale sia il debito tecnico attualmente presente.
Non solo: ci suggerisce anche come rifattorizzare il codice per migliorarne la comunicatività e chiarezza.