TDD patterns and TDD strategies Extreme Programming Agile Software Development

1. TDD Patterns and TDD Strategies
Alessandro Ceseno
contact me, my website is: www.alexceseno.it
Add me on Linkedin:
http://www.linkedin.com/in/alessandroceseno

2. TDD Patterns
Test
Come fare TDD
Aggiungi un test
Fai fallire un test (barra rossa)
Modica il test per vedere la barra verde (tutti i test eseguiti
con successo)
Refactoring verificando che:
- funzioni
- non vi é duplicazione di codice

3. Isolated Test
Come capire se funziona la tua classe?
Scrivi un test automatico.
Il tuo test è isolato se non da problemi:
nell' essere eseguito in modo concorrente con altri test
non si basa su un altro test (ogni test dovrebbe ricreare il
suo contesto e non dipendere da un altro test)
non si basa su un sistema esterno (FS, Network,etc.)
non necessita di un ambiente con una particolare
configurazione (“It worked on my machine!”)
se fallisce non test il messaggio di errore non indica
chiaramente perchè fallisce il test

4. Test list
Crea una lista dei test
Mentre scrivi test e codice applicativo,
se individui altri test aggiungili alla tua lista di test

5. Test First
Scrivi il test prima del codice applicativo
Qual'e il prossimo test?
Il prossimo test è quello che ti insegna qualcosa e quello in
cui ti senti più confidente

6. Test Data
Quali dati per il test si devono utilizzare?
Il codice di test dovrebbe essere il più leggibile e semplice
possibile, quindi la struttura dei dati di test da utilizzare è
quella che consente leggibilità e semplicità

7. Evident Data
I risultati che ci si aspetta e i risultati attuali
devono essere chiari ed evidenti

8. TDD Strategies
I tre approcci principali di implementazione e design nel
TDD:
- Write the obvious implementation (Scrivi il caso più
evidente e più semplice)
- Fake it (till you make it). Essendo una tecnica
incrementale, inizia anche con un fake test.
Generalizza solo quando hai due o tre esempi di test
- Triangulate. Il passo successivo è l'implementazione
dell'algoritmo corretto.

9. Considerazioni:
Considerare i test affinchè non vi siano ridondati test,
i test ridondanti sono test che non creano nuove distinzioni
di comportamento.
redundancy code --> può generare eccessivi problemi di
manutenzione
quindi anche
redundancy test --> possono generare eccessivi problemi
di manutenzione
Arrivi al design desiderato solo rimuovendo la duplicazione,

10. Il TDD è un modo di gestire la "paura" nello sviluppo?
È un modo di gestire il coraggio.
Ti consente di fare tentativi semplici e corti come numero di
linee di codice, tentativi che ti consentono di capire il
funzionamento in un tempo relativamente breve.
Consentono una miglior comunicazione (perchè i test si
capisco, o meglio si dovrebbero capire, se il TDD è fatto
bene)

11. Se hai un test "grande" che si rompe, introduci un test
"piccolo" (in questo modo isoli il problema), risolvi il
problema e poi reintroduci il test grande.
Broken test: viene utilizzato affinchè quando si ritorna su
una sessione di programmazione si sa esattamente da
dove iniziare.

12. Break: fare una pausa quando si sente di aver bisogno di
una pausa.
Cheap Desk, Nice Chair.

13. Come individuare test scritti male:
codice di setup con molte linee
duplicazione di codice che vi è nel setup nelle altre parti
della classe
test unitari lunghi da eseguire
test fragile: i test si rompono ma non si sa il perchè si
rompono

14. Bibliografia:
Kent Beck - Test Driven Development: By
Example

15. TDD Patterns and TDD Strategies
Alessandro Ceseno
contact me, my website is: www.alexceseno.it
Add me on Linkedin:
http://www.linkedin.com/in/alessandroceseno