Использование разных свойств Spring для интеграционных тестов

Question

Я тестирую с Selenium веб-приложение, разработанное с помощью Spring, чтобы убедиться, что веб-приложение отображает нужные данные для пользователя и что он способен делать все, что в спецификации.

Другие разработчикииспользование поддельной базы данных Hibernate в памяти (HSQLDB) для модульного тестирования.Я должен использовать реальную БД, используемую программой для тестирования, очевидно.Параметры JDBC для контекста приложения Spring загружаются Spring во время выполнения (или во время компиляции для построения файла WAR).Spring использует свойства, найденные org.springframework.beans.factory.config.PropertyPlaceholderConfigurer для настройки контекста приложения для веб-приложения и тестов, а файлы конфигурации XML совместно используются тестами и веб-приложением.

Свойствадолжны отличаться в зависимости от профиля Maven, модульных тестов или интеграционных тестов.

Я попробовал несколько подходов, но безуспешно:

• разработка моих собственных DAO с использованием SQL-запросов более низкого уровня.Это настоящая трата времени и решение последней инстанции.Из-за ограничений внешнего ключа и изменений модели базы данных, а также из-за того, что приложение имеет довольно солидный (проверенный модулем) набор DAO, это действительно самый тупой вариант.
• с использованием фильтров Maven и определения там свойств JDBC,Проблема заключается в том, что свойства являются общими для основного приложения и модульных тестов, поскольку цель tomcat: redeploy включает в себя модульные тесты.Приложение не может подключиться к реальной БД.
• , имеющей разные свойства в разных папках.Spring совершенно не заботится о дополнительных ресурсах, определенных в конфигурации профилей Surefire, с testResources или resources .Странно то, что этот подход прекрасно работает для разных параметров JDBC для каждой среды в основном приложении.У нас есть несколько папок в src / main / resources, которые содержат свойства, переопределяющие свойства по умолчанию в src / main / resources.Это просто не работает так же для src / test / resources.Я даже не знаю, как я мог найти причину этого поведения.
• имеет Spring, загружающий различные файлы свойств на основе пользовательских параметров Maven.Те же самые свойства используются для основного приложения и модульных тестов.Spring также жалуется, когда не может найти файлы свойств (вынуждает меня создавать каталоги с пустыми файлами только для завершения сборки).

Почему текущая конфигурация сборки с профилем разработчика (разработчик,тестовый сервер ...) + одновременно запущен тестовый профиль (модульные тесты) и свойства не перекрывают друг друга?Потому что Maven заставит Spring взглянуть на src / test / resources при запуске модульных тестов и src / main / resources при запуске цели сборки.К сожалению, для интеграционных тестов конфигурации по умолчанию не существует.

Answer 1

То, как мы это делаем, основывается на выборе файла свойств из переменной, поэтому заполнитель свойства весной выглядит следующим образом:

<context:property-placeholder location="classpath:db.${TARGET_ENV}.properties" />

И тогда у вас есть выбор определения TARGET_ENV какпеременная окружения или передача ее в maven с помощью -DTARGET_ENV = ...

Answer 2

Для модульных тестов у вас может быть файл свойств с тем же именем, что и в производственном процессе, который будет переопределять производственный, так как он ранее находился в пути к классам.например, у вас могут быть производственные свойства на src/main/resources/my.properties и файл переопределения для модульных тестов на src/test/resources/my.properties.

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

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

Еще одна вещь, которую вы можете попробовать, это использовать пружину @Profile s.Но используя их, вы помещаете в свой код некоторые непроизводственные настройки, что является плохой практикой.