2016-08-04 5 views
0

Я хотел ускорить автоматическое приемочное тестирование API, и лучшим способом, который я нашел, было создание конечной точки API, которая позволила автоматические приемочные испытания чтобы стереть мою базу данных после каждого тестового прогона. Это дало мне значительные улучшения в производительности по сравнению с другими методами.Импортированная пружина MVC @Controller недоступна в тесте maven или предоставленных областям

Однако, кажется, плохая идея отправить мой API с конечной точкой, позволяющей удалить все содержимое базы данных. Даже если я гарантирую конечную точку, это все еще кажется плохой идеей.

Итак, чтобы избежать доставки конечной точки удаления, я включил @Controller с конечной точкой удаления в свой собственный модуль maven, а затем попытался включить этот модуль maven в свой API, используя область проверки «maven» (а затем «предоставил» когда это не сработало. К сожалению, контроллер с логикой удаления, похоже, не найден, если я использую область «test» или «provided». Он обнаруживается, когда я импортирую область по умолчанию (или ядро ​​явно не задано).

Что мне не хватает? Почему я не пытаюсь работать?

ответ

0

Вы можете использовать пружинные профили. Комментирование контроллер с @Profile аннотацию:

@Controller 
@Profile("acceptance") 
public class SpecialController { 
    @RequestMapping("/stuff") 
    public void doDangerousStuff() { 
     // ... 
    } 
} 

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

Я понятия не имею, как запустить приложение, но если вы используете mvn spring-boot:run, вы можете использовать:

mvn spring-boot:run -Dspring.profiles.active=acceptance 

Тем не менее, я считаю, ваш случай использования немного странно, потому что если вы используете пружинные загрузки -starter-test вы уже можете писать тесты JUnit и факсимильные компоненты из приложения в своих тестах, чтобы вы могли автоповторить свои репозитории/DAO и стереть данные непосредственно вместо того, чтобы подвергать его воздействию API.

+0

Вы правы, «вы могли бы автоповторить свои репозитории/DAO и стереть данные непосредственно вместо того, чтобы подвергать его воздействию API», гораздо лучший вариант. Поскольку эти тесты являются BDD, вызывающими конечные точки REST, это не перешло мне в голову, я мог просто автоподписать мой bean-компонент. Тем не менее, bean не найден, если я использую тест или предоставленный объем ... не знаю, почему .... –

 Смежные вопросы

  • Нет связанных вопросов^_^