È possibile scrivere un test unitario (al contrario di un test di integrazione) nel seguente scenario:
- Ho una lista di oggetti
Foo, alcuni dei quali esistono già nel database, altri no - Voglio scorrere l'elenco, aggiornare quelli che ho già nel database e aggiungerne di nuovi
Quindi, scrivo un test che ha un FooImporter con un metodo importFoos(List<Foo> foos) . E poi ho bisogno di prendere in giro il mio livello DAO, quindi metto a punto il FooDAO che viene iniettato nella FooImporter ... e poi mi sento come se stessi verificando l'implementazione, non il comportamento! Nel mio test finisco con un sacco di aspettative sulle chiamate (ad es. Ho inserito un record Foo "esistente", poi ho preso in giro il comportamento di FooDAO per restituire true per il controllo di duplicato e quindi aggiungere un aspettativa per il comportamento dell'inserto ecc.)
Quindi posso effettivamente testare questa unità vicino al livello dati in modo efficace, o dovrei essere un test di integrazione? E se sì, non può essere fatto in modo sensato in modo TDD?
(Prima che questo venga contrassegnato come duplicato, questa domanda riguarda in realtà il discorso che ha ispirato questa domanda, ma la risposta in realtà non mi convince che questo risolva l'accoppiamento dei test con il comportamento di implementazione.)