Модульное тестирование соединения с базой данных и общие вопросы о коде, зависящем от базы данных, и модульное тестирование

Question

Если у меня есть метод, который устанавливает соединение с базой данных, как этот метод можно протестировать? Возврат bool в случае успешного соединения - это один из способов, но лучше ли это?

Из метода тестируемости лучше ли иметь метод соединения в качестве одного метода и метод для возврата данных отдельным методом?

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

РЕДАКТИРОВАТЬ: Для последнего пункта, чтобы проверить данные, если это должен быть список автомобилей, то я могу проверить, что это реальные модели автомобилей. Или, если они представляют собой набор веб-серверов, я могу иметь список существующих веб-серверов в системе, вернуть его из тестируемого кода и получить результат теста. Если результаты различаются, проблема в данных, а в запросе нет?

Thnaks

Answer 1

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

Метод подключения определенно должен быть отделен от выборки данных.Фактически, ваше соединение должно исходить от фабрики, чтобы вы могли объединить его.Что касается тестирования соединения, то на самом деле все, что вы можете проверить, это то, что ваша конфигурация верна, если вы подключаетесь к БД.Вы не должны пытаться протестировать свой пул соединений, так как это, вероятно, должна быть библиотека, написанная кем-то другим (dbcp или c3p0).Более того, вы, вероятно, не можете это проверить, поскольку ваши модульные / интеграционные / функциональные тесты НИКОГДА не должны подключаться к базе данных производственного уровня.

Что касается проверки работоспособности вашего кода доступа к данным.Это функциональное тестирование, включающее в себя множество фреймворков и поддержки.Вам нужна отдельная БД для тестирования, возможность создавать схему на лету во время тестирования, вставлять любые статические данные в таблицу и возвращать базу данных в известное чистое состояние после каждого теста.Кроме того, эта БД должна создаваться и запускаться таким образом, чтобы 2 человека могли одновременно выполнять тесты.Особенно, если у вас более одного разработчика, плюс поле автоматического тестирования.

Утверждения должны быть сопоставлены с данными, которые являются либо статическими данными (например, список состояний, который не часто меняется), либо с данными, которые являютсявставляется во время теста и удаляет послесловия, чтобы он не мешал другим тестам.

РЕДАКТИРОВАТЬ: Как уже отмечалось, есть рамки, чтобы помочь с этим.DBUnit довольно распространен.

Answer 2

Вы можете получить идеи от здесь .Я бы использовал фиктивные объекты при модульном тестировании БД.

В противном случае, если приложение огромно и вы выполняете длинные и сложные модульные тесты, вы также можете виртуализировать сервер БД и легко вернуть его к сохраненному снимку для запуска.снова ваши тесты в известной среде.

Answer 3

Используя мою платформу Acolyte (https://github.com/cchantep/acolyte), вы можете имитировать любую поддерживаемую JDBC БД, описывая случаи (как обрабатывать каждый выполненный запрос / обновление) и какой набор результатов / updatecount возвращать в каждом случае (описывать приборы в виде строки список запросов, количество обновлений).

Такое соединение может использоваться напрямую, минуя экземпляр, где требуется JDBC, или регистрироваться с уникальным идентификатором в пространстве имен URL JDBC jdbc:acolyte:, чтобы быть доступным для соединения, получающего код, благодаря разрешению URL JDBC.

Каким бы ни был способ создания соединения, Acolyte хранит каждый из них изолированным, что подходит для модульного теста (без дополнительной очистки, выполняемой на тестовой БД).

Так как случаи персистентности могут отправляться в другое изолированное соединение, вам больше не нужен большой базы данных "все в трудных для управления" (или файл фикстур): его можно легко разделить на различные соединения, например, один на постоянный метод / модуль.

Мой каркас Acolyte можно использовать либо в чистом Java, либо в Scala.

Answer 4

Для соединения с базой данных установите тестирование: вы можете позволить соединению выполнить очень простой SQL в качестве метода тестирования.Некоторые серверы приложений имеют такую ​​конфигурацию, следующий фрагмент из конфигурации JBoss DB:

<!--  sql to call on an existing pooled connection when it is obtained from pool 
<check-valid-connection-sql>some arbitrary sql</check-valid-connection-sql>

Answer 5

Если цель состоит в том, чтобы проверить функциональность метода, а не оператора базы данных SP или оператора SQL, то вы можете рассмотреть возможность внедрения зависимости в смысле интерфейса поставщика данных. Другими словами, ваш класс использует интерфейс с методами, возвращающими данные. Реализация по умолчанию использует базу данных. Реализация модульного теста имеет несколько вариантов:

• издевательства (NMock, Moq и т. Д.), Отлично, я живу издевательством.
• база данных в памяти
• статическая база данных со статическими данными

Мне не нравится ничего, кроме первого. Как правило, программирование интерфейсов всегда намного более гибко.