((( 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 :
- Istanzia l'oggetto usando Stub per eventuali dipendenze esterne
- Inizializza lo stato dell'oggetto da testare
- Richiama l'operazione da testare
- Verifica che lo stato finale dell'oggetto è quello atteso
Quindi implementa in pair anche un interation based unit test evidenziando i diversi passi :
- Dichiara i mock degli oggetti di cui si vuole testare l'interazione usando Strict mock
- 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
- Dichiara le Expectation sulle interazioni che si aspetta con i mock
- Richiama l'operazione da testare
- 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
Print | posted @ sabato 6 giugno 2009 18.03