Есть ли способ предотвратить повторное построение базы данных Maven Test?

Question

Меня недавно попросили эффективно продать мой отдел по модульному тестированию.Я не могу сказать вам, как это меня взволновало, но у меня есть одна проблема.Мы используем JUnit с Spring и Maven, и это означает, что каждый раз, когда вызывается mvn test, он перестраивает базу данных.Очевидно, что мы не можем интегрировать это с нашим рабочим сервером - это убило бы ценные данные.

Как предотвратить восстановление, не сказав maven пропустить тестирование?

Лучшее, что я мог понять, - это назначить скрипт для работы в тестовой базе данных (разрывы строк добавлены для удобства чтения):

mvn test 
   -Ddbunit.schema=<database>test 
   -Djdbc.url=jdbc:mysql://localhost/<database>test?
        createDatabaseIfNotExist=true&amp;
        useUnicode=true&amp;characterEncoding=utf-8 

Не могу не подумать, что должно бытьлучший способ.

Мне особенно интересно узнать, есть ли простой способ сказать, что Maven должен запускать тесты только на определенных классах без создания чего-либо еще?mvn -Dtest=<test-name> test по-прежнему восстанавливает базу данных.

======= update =======

Кусок яйца на моем лице здесь.Я не осознавал, что использую одну и ту же переменную в двух местах, а это означает, что POM использовал переменную «skip.test» как для перестройки базы данных, так и для запуска тестов ...

Answer 1

Обновление: Я полагаю, что DBUnit выполняет перестройку БД, потому что это сказано в методе настройки теста.Если вы измените свой метод настройки, вы можете отменить восстановление БД.Конечно, вы должны сделать это так, чтобы вы получали сброс БД, когда вам это нужно, и опускали его, когда вы этого не делаете.Моя первая ставка будет использовать системное свойство для управления этим.Вы можете установить свойство в командной строке так же, как вы уже это сделали с jdbc.url et al.Затем в методе настройки вы добавляете if для проверки этого свойства и выполняете сброс БД, если он установлен.

Тестовая база данных, полностью отделенная от вашей производственной БД, безусловно, является лучшим выбором, если вы можетеиметь это.Вы можете даже использовать, например, Derby , БД в памяти, которая может работать встроенной в JVM.Но в случае, если вы абсолютно не можете иметь отдельную БД, используйте хотя бы отдельную схему тестирования внутри этой БД.

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

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

Надеюсь, это поможет.

Answer 2

Мы используем JUnit с Spring и Maven, и это означает, что каждый раз, когда вызывается mvn test, он перестраивает базу данных.

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

Как предотвратить восстановление, не сказав maven пропустить тестирование?

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

Answer 3

Юнит-тесты по определению работают только на одном компоненте в системе. Вы не должны пытаться писать модульные тесты, которые интегрируются с какими-либо внешними сервисами (веб, БД и т. Д.). Решение, которое у меня есть, состоит в том, чтобы использовать хорошую среду для моделирования, чтобы заглушить поведение любых зависимостей, которые имеют ваши компоненты. Это поощряет хорошие интерфейсы API, так как большинство фальшивых фреймворков лучше всего работают с простыми интерфейсами. Было бы лучше создать интерфейс шаблона репозитория для любых взаимодействий с вашей БД, а затем макетировать impl каждый раз, когда вы тестируете класс, взаимодействующий с ним. Затем вы можете функционально протестировать ваш репозиторий impl отдельно. Это также дает дополнительное преимущество, заключающееся в том, что ваши модульные тесты будут достаточно быстрыми, чтобы оставаться частью вашего CI, чтобы ваш цикл обратной связи был максимально быстрым.