Хорошая стратегия для тестирования Spring Framework от конца до конца

Question

Так что это скорее «большой» вопрос, но то, что я пытаюсь выполнить следующее:

У меня есть Spring MVC приложения,, JDBC (MySQL) и JSP, работающие на tomcat.

Моя цель - проверить весь «стек» с использованием надлежащего метода.

Что мне до сих пор является Junit с использованием Selenium для имитации фактического пользователя, взаимодействующего с приложением (для этого требуется фиктивная учетная запись) и выполнения различных проверок, таких как, см., Присутствует ли элемент на странице, база данных имеет определенное значение или значение соответствует базе данных.

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

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

Я смотрел тест Spring, но он позволяет тестировать вне контейнера сервлетов, поэтому JSP и Javascript не могут быть доступны.

Я видел DBUtils документацию, но не уверен, что это поможет мне в этом случае

Итак, мои коллеги разработчиков, я хотел бы попросить советы для:

• Run селен тестов на вершине из базы данных издевались
• Разрешить различные конфиги на тест
• Keep совместимость с Maven/Gradle

Answer 1

Я начал с заказанной функции autwire для поддержки такого рода stubbing.

Это, в основном, идея, что я взял на себя роль в структуре Seam, с которой я работал в прошлом, но я не мог найти подобную вещь весной.
Идея состоит в том, чтобы иметь аннотацию приоритета (fw, app, mock, ...), которая будет использоваться для разрешения текущей реализации автообновленного компонента. Это легко уже в xml, но не с java-конфигурацией.

Таким образом, у нас есть наши обычные бобы хранилища с приоритетом приложения и тестовый пакет, накладывающий эти классы с макетом приоритета. Если оба параметра находятся в переменной класса, то пружина обычно терпит неудачу, если исключение дублированного компонента будет найдено. В нашем случае расширенный beanfactory просто берет компонент с наивысшим приоритетом.

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

! Хотя это хороший подход к заглушке, так что бобы для тестирования я бы не использовал его для замены определения базы данных, а скорее использовал базу данных inmemory, такую ​​как hsql, как уже упоминалось ранее в предыдущих ответах. !