Evita i test sui controller. Per quel che mi riguarda, duplicano le
funzionalit
degli integration test. Una discussiono a riguardo la trovi
quihttp://betterspecs.org/#integration
.
Evita i test sui controller. Per quel che mi riguarda, duplicano le
funzionalit
degli integration test. Una discussiono a riguardo la trovi
quihttp://betterspecs.org/#integration
.
Lettura interessante, ed effettivamente spesso mi chiedo se un
determinato test debba essere inserito nel controller o nel model.
Flex, dovresti fare il contrario, prima gli integration, poi gli unit.
perche’ ?
Voglio dire prima testo ad esempio che non si possibile creare un record
con un campo unico duplicato e poi verifico con gli integration il
processo di creazione di quel record.
Per quanto riguarda gli integration test, consiglio caldamente la
visione di questa [2] presentazione di Reisenberger. Sinceramente non
capisco perch si considerino i test dei controller uno spreco di
tempo e come si pensa di avere una copertura decente testando
unitariamente solo i model e testando tutto il resto full stack…
IMHO: Se testi gli unit prima, corri il rischio di testare funzionalit
che non servono. Con gli integration invece hai una visione d’insieme
degli stati del programma. Che senso ha testare per la duplicazione di
un record se un caso che non si presenta mai?
Io mi faccio portare dai test.
Comincio dall’integration. Il primo fallimento ovviamente arriva sul
routing che magari non esiste.
Aggiungo il test della rotta e la rotta stessa.
Poi ovviamente il controller non ha la action e auindi aggiungo il test
del controller per la action in questione etc…
Quando l’integration passa ho fatto tutto quello che dovevo testando
tutti i vari aspetti.
+1 per l’approccio e la spiegazione proposte da Andrea: procedere
outside-in mi permette di rendermi conto, lungo il percorso di
implementazione, se ho le idee chiare su quel che sto facendo. E, nel
caso
non le abbia, di fare il punto della situazione e ripartire.
Per me procedere outside-in significa partire dallo scrivere i test
relativi alla parte di software più “vicina” all’utente (inteso in senso
generico: potrebbe essere una persona fisica o, nel caso di API, una
macchina o, più in generale, qualsiasi entità che interagisce con il
software che sto scrivendo) per scendere negli strati sottostanti (fino
a
fermarmi, idealmente, dove iniziano i test delle librerie su cui baso lo
sviluppo).