Каким образом можно протестировать код, который использует запросы, специфичные для MySQL,

Question

Я собираю данные и храню эти данные в базе данных MySQL с использованием Java. Кроме того, я использую Maven для создания проекта TestNG в качестве тестовой среды и Spring-Jdbc для доступа к базе данных. Я реализовал уровень DAO, который инкапсулирует доступ к базе данных. Помимо добавления данных с использованием классов DAO, я хочу выполнить некоторые запросы, которые агрегируют данные и сохраняют результаты в некоторых других таблицах (например, материализованные представления).

Теперь я хотел бы написать несколько тестовых таблиц, которые проверяют, работают ли классы DAO так, как должны. Поэтому я подумал об использовании базы данных в памяти, которая будет заполнена некоторыми тестовыми данными. Поскольку я также использую MySQL-специфические запросы SQL для агрегирования данных, я пошел в неприятности:

1. Во-первых, я думал, что просто использовать функциональные возможности встраиваемых баз данных, предоставленную Spring-JDBC для создания экземпляра встроенной базы данных , Я решил использовать реализацию H2. Там я столкнулся с трудностями из-за запросов агрегирования, которые используют контент, специфичный для MySQL (например, такие функции времени, как DATE()). Другим недостатком этого подхода является то, что мне нужно поддерживать два файла ddl - фактический файл ddl, определяющий таблицы в MySQL (здесь я определяю кодировку и добавляю комментарии к таблицам и столбцам, обе функции зависят от MySQL); и тестовый файл ddl, который определяет те же таблицы, но без комментариев и т. д., так как H2 не поддерживает комментарии.
2. Я нашел описание для использования MySQL в качестве встроенной базы данных, которую я могу использовать в тестовых случаях (http://literatitech.blogspot.de/2011/04/embedded-mysql-server-for-junit-testing .html). Это звучало действительно многообещающе для меня. К сожалению, это не сработало: произошел «MissingResourceExcpetion» «Ресурс» 5-0-21/Linux-amd64/mysqld «не найден». Кажется, что драйвер не может найти демона базы данных на моей локальной машине. Но я не знаю, что я должен искать, чтобы найти решение для этой проблемы.

Теперь я немного застрял, и мне интересно, если бы я создал архитектуру по-другому. У кого-то есть некоторые подсказки, как я должен настроить соответствующую систему? У меня есть два других варианта:

1. Вместо использования встроенной базы данных я отправлю с использованием собственного экземпляра MySQL и настрою базу данных, которая используется только для тестовых таблиц. Эти параметры звучат медленно. На самом деле, возможно, мне захочется позже установить сервер CI, и я подумал, что использование встроенной базы данных будет более подходящим, поскольку тест будет работать быстрее.
2. Я удаляю все специфичные для MySQL данные из SQL-запросов и использую H2 как встроенную базу данных для тестирования. Если этот вариант является правильным выбором, мне нужно будет найти другой способ протестировать SQL-запросы, которые агрегируют данные в материализованные представления.
3. Или есть третий вариант, который я не имею в виду?

Буду признателен за любые подсказки.

Спасибо, XComp

Answer 1

Если это не представляется возможным получить базу данных MySQL в памяти для работы я предлагаю использовать базу данных H2 для «простых» тестов и выделенный экземпляр MySQL для тестирования MySQL- конкретных запросов.

Кроме того, тесты для реальной базы данных MySQL могут быть сконфигурированы как интеграционные тесты в отдельном профиле maven, так что они не являются частью обычной сборки maven. На сервере CI вы можете создать дополнительное задание, периодически выполняющее тесты MySQL, например. ежедневно или каждые несколько часов.При такой настройке вы можете хранить и тестировать свои запросы, зависящие от продукта, в то время как ваша регулярная сборка не будет замедляться. Вы также можете запустить обычную сборку, даже если тестовая база данных недоступна.

Есть хороший плагин maven для интеграционных тестов под названием maven-failsafe-plugin. Он обеспечивает шаги до и после интеграции, которые можно использовать для настройки тестовых данных перед тестированием и для очистки базы данных после тестов.

Answer 2

Я создал плагин Maven именно для этой цели: jcabi-mysql-maven-plugin. Он запускает локальный сервер MySQL на этапе pre-integration-test и отключает его на post-integration-test.