7
En el siguiente código el problema es que no puedo probar dao.add() sin usar dao.list(). Size() y viceversa.¿Cómo probar "agregar" en DAO sin usar "buscar", etc.?
¿Este enfoque es normal o incorrecto? Si es incorrecto, ¿cómo se puede mejorar?
public class ItemDaoTest {
// dao to test
@Autowired private ItemDao dao;
@Test
public void testAdd() {
// issue -> testing ADD but using LIST
int oldSize = dao.list().size();
dao.add(new Item("stuff"));
assertTrue (oldSize < dao.list().size());
}
@Test
public void testFind() {
// issue -> testing FIND but using ADD
Item item = new Item("stuff")
dao.add(item);
assertEquals(item, dao.find(item.getId()));
}
}
¿Estás buscando pruebas de integración o unidad? – davidfrancis
Dígame :) En este escenario en particular, usar solo el sentido común me parece más una prueba de integración. Pero ya sabes, después de todo, solo quiero asegurarme de que mi DAO funcione, eso es todo. – Xorty
Sí, es un dolor. No estoy seguro de que pueda terminar con pruebas unitarias debido a la dependencia que tiene el dao. ¿Cómo funciona el dao? Personalmente, intentaría evitar que tu prueba dependa de una base de datos externa e intentará colgar o burlar la capa de acceso a la base de datos, como se sugiere en una de las respuestas. Habiendo dicho eso, nunca es tan tranquilizador como una verdadera prueba de integración dependiente de db. – davidfrancis