Автор оригинала: Vlad Mihalcea.
Модульное тестирование требует изоляции отдельных компонентов от их зависимостей. Зависимости заменяются на насмешки , которые имитируют определенные варианты использования. Таким образом, мы можем проверить поведение тестируемого компонента в различных сценариях внешнего контекста.
Веб-компоненты могут быть протестированы с помощью модульных служб бизнес-логики. Службы могут быть протестированы на основе фиктивных хранилищ доступа к данным. Но уровень доступа к данным не является хорошим кандидатом для модульного тестирования , потому что операторы базы данных должны быть проверены на соответствие реально работающей системе баз данных.
В идеале наши тесты должны выполняться с производственной базой данных. Но использование выделенного сервера баз данных нецелесообразно, так как у нас, скорее всего, есть несколько разработчиков для запуска таких наборов интеграционных тестов. Для изоляции параллельных тестовых запусков каждому разработчику потребуется специальный каталог базы данных. Добавление инструмента непрерывной интеграции усугубляет ситуацию, поскольку параллельно придется запускать больше тестов.
Урок 1: Нам нужна разветвленная база данных с привязкой к набору тестов
При запуске набора тестов база данных должна быть запущена и доступна только для этого конкретного экземпляра набора тестов. В основном у нас есть следующие варианты:
- Встроенная в память база данных
- Временный процесс создания базы данных
Ошибочность тестирования базы данных в памяти
Java предлагает несколько вариантов реляционных баз данных в памяти на выбор:
Встраивание базы данных в память выполняется быстро, и каждая JVM может запускать свою собственную изолированную базу данных. Но мы больше не тестируем на основе реального производственного компонента database engine, потому что наши интеграционные тесты проверят поведение приложения для непроизводственной системы баз данных.
Использование инструмента ORM может создать ложное впечатление, что все базы данных равны, особенно когда весь сгенерированный SQL-код соответствует стандарту SQL-92 .
Что хорошо для поддержки базы данных инструмента ORM, может лишить вас возможности использовать функции запросов, специфичные для базы данных ( Оконные функции , Общие табличные выражения , СВОДНЫЕ ).
Таким образом, база данных интеграционного тестирования в памяти может не поддерживать такие расширенные запросы. Это может привести к сокращению охвата кода или к тому, что разработчики будут использовать только общие, но ограниченные функции SQL-запросов.
Даже если ваш производственный компонент database engine предоставляет вариант в памяти , все равно могут существовать операционные различия между фактической и облегченной версиями базы данных.
Создание временной базы данных, подобной производственной
Тестирование на реальной производственной базе данных гораздо более ценно, и именно поэтому я стал ценить эту альтернативу.
При использовании MongoDB мы можем выбрать встроенный плагин mongo . Этот проект с открытым исходным кодом создает процесс внешней базы данных , который может быть привязан к текущему жизненному циклу набора тестов.
Если вы используете Maven, вы можете воспользоваться встроенным плагином maven-maven :
com.github.joelittlejohn.embedmongo embedmongo-maven-plugin ${embedmongo.plugin.version} start start ${embedmongo.port} ${mongo.test.version} ${project.build.directory}/mongotest 127.0.0.1 stop stop
При запуске плагина выполняются следующие действия:
- Загружается пакет MongoDB
- При запуске нового набора тестов пакет MongoDB распаковывается в уникальном месте в папке OS temp
- Запускается встроенный экземпляр MongoDB.
- В течение всего срока службы текущего набора тестов вы можете просмотреть встроенный процесс монго:
- Когда набор тестов завершен, встроенный монго останавливается
Плагин embed-mongo нигде не работает медленнее, чем в любых системах баз данных с отношениями в памяти. Это заставляет меня задуматься, почему для СУБД с открытым исходным кодом (например, PostgreSQL) нет такой опции. Это отличная идея проекта с открытым исходным кодом, и, возможно, Flapdoodle OSS также предложит поддержку реляционных баз данных.
Код доступен на GitHub .