Un esempio di semplicità col TDD: state based vs interaction based





    ((( continuo la serie di post pratici sulla semplicità )))


Gino ha a disposizione l'intero giorno in pair programming col collega per chiarirgli la differenza tra state e interaction testing. Per farla semplice da dove comincia?



Comincia in pair a implementare uno state based unit test evidenziando i passi :
  1. Istanzia l'oggetto usando Stub per eventuali dipendenze esterne
  2. Inizializza lo stato dell'oggetto da testare
  3. Richiama l'operazione da testare
  4. Verifica che lo stato finale dell'oggetto è quello atteso
Quindi implementa in pair anche un interation based unit test evidenziando i diversi passi :
  1. Dichiara i mock degli oggetti di cui si vuole testare l'interazione usando Strict mock
  2. Inizializza lo stato dell'oggetto da testare passandogli i mock e usando Stub per eventuali dipendenze esterne necessarie all'oggetto per funzionare ma di cui non ci interessa testare l'interazione
  3. Dichiara le Expectation sulle interazioni che si aspetta con i mock
  4. Richiama l'operazione da testare
  5. Verifica che le Expectation siano soddisfatte e nessun'altra interazione non dichiarata sia avvenuta con i mock


Gino passa la tastiera al collega, aspetta che emergano le prime domande sulle funzioni avanzate di mock e stub
(mockkare classi concrete o metodi statici, mock ibridi a metà mock e a metà stub, sintassi "avanzate" riducono la frizione dei mock) per superare difficoltà emerse durante la scrittura dei test.

E mostra che il "bisogno" di funzioni avanzate del tool di mocking in realtà è lo smell che ci guida dove il disegno della classe testata va migliorato, e lo migliora





Tags :   |  |  |

Print | posted @ Saturday, June 6, 2009 6:03 PM

Comments on this entry:

Gravatar # re: Un esempio di semplicità col TDD: state based vs interaction based
by Leonardo at 6/9/2009 9:32 AM

Magari potresti fare diversi PDF (raccolte di post magari con piccoli rintocchi come l'aggiunta di un sommario, l'eliminazione di eventuali ripetizioni dovute alla natura periodica dei post ecc... se dai un'occhiata ai link che ti ho lasciato puoi vedere un buon libro fatto proprio così) e potresti dividerli per categoria ad es. sviluppo agile, refactoring, ecc... ed aggiornarli trimestralmente/semestralmente coi nuovi post in modo da rendere disponibile qualcosa di sempre aggiornato.
Comments have been closed on this topic.