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

Я собираю данные и храню эти данные в базе данных 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. Я удаляю из SQL-запросов все, что связано с MySQL, и использую H2 в качестве встроенной базы данных для тестирования. Если этот вариант является правильным выбором, мне нужно будет найти другой способ тестирования SQL-запросов, которые объединяют данные в материализованные представления.
  3. Или есть 3-й вариант, который я не имею в виду?

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

Спасибо, XComp.


mysql maven spring-jdbc testng embedded-database
person XComp    schedule 28.06.2012    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

person Stefan Ferstl    schedule 08.07.2012

arrow_upward
8
arrow_downward

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

person yegor256    schedule 09.10.2013