Тестирование модулей DAO

Я рассматривал EasyMock и учебники/примеры вокруг его использования для классов DAO для Unit Testing для теста "снаружи контейнера". Тем не менее, я думаю, что большинство из них говорит о тестировании уровня обслуживания вместо этого, издеваясь над классом DAO. Я немного смущен, действительно ли это, как вы Unit Test слой DAO?

Некоторые скажут, что тесты, взаимодействующие с БД и EJB, на самом деле являются тестами интеграции, а не модульными тестами, но тогда как вы узнаете, правильно ли ваш SQL (при отсутствии ORM), и ваши DAO вставляют/запрашивают правильные данные из вашего реального (чтение, локальная база данных, похожая на базу данных)?

Я читал, что DBUnit - это решение для такой ситуации. Но мой вопрос заключается в использовании инфраструктуры, такой как DBUnit "внешний контейнер". Что, если DAO зависит от некоторых EJB, как мы обрабатываем транзакции, что произойдет, если есть триггеры, которые обновляют другие таблицы в ваших вставках?

Как лучше всего использовать Unit Test только DAO с такими зависимостями?

Ответ 1

Лично, я unit test DAO, попав в какую-либо тестовую базу данных, желательно, чтобы тот же тип базы данных (а не база данных SAME, очевидно), которую ваше приложение использует в процессе производства.

Я думаю, что если вы это сделаете, тест будет скорее интеграционным тестом, потому что он имеет зависимость от текущей базы данных. Этот подход имеет то преимущество, что он как можно ближе к вашей рабочей среде. У него есть недостатки, требующие тестовой конфигурации, вам нужна работающая тестовая база данных (локальная на вашем компьютере или где-то в вашей среде), и тесты могут занять больше времени. Вы также должны обязательно откатить тестовые данные после выполнения тестов.

Как только DAO будут протестированы, определите их в unit test своих сервисах.

Ответ 2

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

Для тестирования сопоставления с базой данных DBUnit полезно, потому что это позволяет вам указать начальный набор данных перед тестом, чтобы ваш тест начинался из известного состояния и позволяет указать, какое должно быть конечное состояние данных, поэтому вам не нужно писать много кода unit test, утверждающего, что есть, что ожидается.

В идеале, если у вас есть такой инструмент, как Hibernate, который абстрагирует базу данных, вы можете получить с помощью базы данных в памяти, такой как H2 или HSQLDB, поэтому ваши тесты выполняются быстрее и нет базы данных для создания. Если вам нужно использовать настоящую базу данных, убедитесь, что ваши тесты имеют ее сами, поэтому они могут создавать и удалять данные, не влияя или не влияя на другие процессы. На практике наличие базы данных для себя, как локально, так и в средах CI, маловероятно, и использование базы данных в памяти гораздо более практично.

Ответ 3

В дополнение к Koya anwers вы можете использовать HSQLDB для тестирования DAO. Я полагаю, вы используете Spring и Hibernate в своем проекте. Вам потребуются отдельные файлы конфигураций для указания HSQLDB, вам нужно будет вставить данные перед выполнением тестов. Существуют некоторые ограничения на то, что вы можете делать с HSQLDB, но это нормально для общего использования в качестве запросов и объединений. С этим решением можно использовать в непрерывной среде, такой как дженкинс. Тесты интеграции могут использовать HSQLDB, поэтому эта часть не издевается.

Ответ 4

Я использую HSQLDB для тестирования Dao и Service API. Производительность хороша и поддерживает транзакции. Я не пользуюсь EJB. Я использую Hibernate.

Есть некоторые проблемы, которые я знаю о том, что запуск тестов в другой базе данных может замаскировать некоторые из поддерживаемых проблем с базой данных. Но я думаю, что такие проблемы следует уловить в тестах на дым и приём.

С уважением, Койя

Ответ 5

В конечном итоге я решил записать тесты Unit, которые могут запускаться за пределами контейнера, с живой базой данных и для транзакционной поддержки использует автономный диспетчер транзакций (Bitronix), я также могу откат. Я предполагаю, что это еще не делает тесты Pure Unit еще... Хотелось бы услышать мнение ваших людей о таком подходе.