Зависит от: -)
Если ваши классы DAO содержат только код, необходимый для извлечения сущностей из БД, лучше проверить их в отдельных интеграционных тестах *. Код, подлежащий модульному тестированию, является «бизнес-логикой», которую вы можете тестировать модульно, используя фиктивные DAO.
[Обновление] Например. с EasyMock вы можете легко настроить макет для определенного класса (с его расширением класса, даже конкретные классы могут быть смоделированы), сконфигурировать его так, чтобы он возвращал определенный объект из определенного вызова метода, и вставлять его в ваш класс для тестирования.
Сайт EasyMock, похоже, сейчас недоступен, надеюсь, он скоро вернется - тогда вы можете проверить документацию, которая, на мой взгляд, довольно чистая и тщательная, с множеством примеров кода. Без подробностей в вашем вопросе я не могу дать более конкретный ответ. [/ Update]
Если, OTOH, DAO содержат также бизнес-логику, ваш лучший выбор - если вы можете сделать это - это реорганизовать их и вывести бизнес-логику из DAO, тогда вы можете применить предыдущую стратегию.
Но суть в том, что всегда помните девиз модульного тестирования «проверить все, что может сломаться». Другими словами, нам нужно расставить приоритеты в наших задачах и сосредоточить наши усилия на написании тестов, которые приносят наибольшую пользу при наименьших усилиях. Сначала напишите модульные тесты для самых критических, наиболее подверженных ошибкам частей кода. Код, который, на ваш взгляд, настолько прост, что его невозможно сломать, находится ниже по списку. Конечно, желательно проконсультироваться с опытными разработчиками по конкретным частям кода - они могут знать и замечать возможные ловушки и проблемы, о которых вы не знаете.
* модульные тесты должны быть легкими, быстрыми и максимально изолированными от окружающей среды. Поэтому тесты, включающие вызовы реальной БД, - это не модульные тесты, а интеграционные тесты. Хотя технически они могут быть построены и выполнены с помощью JUnit (и, например, DbUnit), они намного сложнее и на несколько порядков медленнее, чем подлинные модульные тесты. Иногда это делает их непригодными для выполнения после каждого небольшого изменения кода, поскольку могут (и часто должны) использоваться регулярные модульные тесты.