Письменные тесты для DAO

Ответ 1

Это зависит: -)

Если ваши классы DAO содержат только код, необходимый для извлечения сущностей из БД, лучше протестировать их в отдельных тестах интеграции *. Код для модульной проверки - это "бизнес-логика", которую вы можете использовать unit test, используя макеты DAO.

[Обновить]. с EasyMock вы можете легко настроить макет для определенного класса (с его расширением класса, даже конкретными классами можно издеваться), configure он возвращает конкретный объект из определенного вызова метода и вводит его в тестируемый класс.

Веб-сайт EasyMock, похоже, сейчас не работает, надеюсь, он скоро вернется - тогда вы сможете проверить документацию, которая ИМХО достаточно чистая и тщательная, с большим количеством примеров кода. Без подробностей в вашем вопросе я не могу дать более конкретного ответа. [/Update]

Если OTOH, DAO содержат также бизнес-логику, ваш лучший выбор - если вы можете это сделать - будет реорганизовывать их и вывести бизнес-логику из DAO, тогда вы можете применить предыдущую стратегию.

Но суть в том, что всегда помните дегустатор тестирования устройства "проверяйте все, что может сломаться". Другими словами, нам необходимо уделить приоритетное внимание нашим задачам и сосредоточить наши усилия на написании тестов, которые принесут наибольшую пользу с наименьшими усилиями. Сначала пишите модульные тесты для наиболее критических, наиболее опасных для ошибок частей кода. Код, который, по вашему мнению, настолько прост, что он не может сломаться, находится дальше по списку. Конечно, рекомендуется проконсультироваться с опытными разработчиками по конкретным фрагментам кода - они могут знать и заметить возможные ловушки и проблемы, о которых вы не знаете.

* Модульные тесты должны быть максимально легкими, быстрыми и изолированными от окружающей среды. Поэтому тесты, которые включают вызовы в реальную БД, не являются модульными, а интеграционными тестами. Несмотря на то, что технически они могут быть построены и выполнены с помощью JUnit (и, например, DbUnit), они намного сложнее и на порядок медленнее, чем настоящие модульные тесты. Иногда это делает их непригодными для выполнения после каждого небольшого изменения кода, поскольку регулярные модульные тесты могут (и часто должны) использоваться.

Ответ 2

Да, вы должны написать модульные тесты для DAO.

Эти модульные тесты могут использовать базу данных в памяти. См. Например: HyperSQL

Статья о том, как использовать HyperSQL для написания тестов на персистентность в Java:

http://www.mikebosch.com/?p=8

Ответ 3

Да. Но мало кто будет утверждать, что он не входит в категорию единичных тестов. Потому что он не будет соответствовать определению unit test за отзыв. Мы называем это интеграционным тестом, где мы тестируем интеграцию кода в базу данных.

Кроме того, я согласен с идеей Бруно здесь. Кроме того, для этого доступны только API-интерфейсы, один из которых - DBUnit.

Ответ 4

Не требуется писать тесты на что угодно. Вы получаете выгоду от написания тестов для своих классов DAO? Возможно.

Ответ 5

Да. Этому есть несколько преимуществ. Как только вы убедитесь, что ваш DAO-уровень работает нормально, исправление дефектов на последующих этапах становится легким.

Ответ 6

Я бы сказал, что мы должны писать модульные тесты для DAO, и одна из самых больших проблем - установка и очистка тестовых данных. Именно в этом я думаю, что рамки, такие как Spring среда тестирования JDBC, могут помочь нам, позволив нам контролировать транзакцию с использованием разных аннотаций. [Пример: @Rollback (true)].

Например, если вы тестируете операцию "создать/вставить", Spring позволяет вам полностью отменить транзакцию после выполнения тестового метода, тем самым всегда оставляя базу данных в ее исходном состоянии.

Вы можете ознакомиться с этой ссылкой для получения дополнительной информации: Spring Тестирование

Это может быть еще более полезно, если для ваших интеграционных тестов, где вы не хотите, чтобы один тест испортил целостность данных, что может привести к сбою другого теста.

Ответ 7

Книга xUnit Test Patterns предлагает массу замечаний в этом вопросе.