Весенний контекстный тест с одним бином - PullRequest
Новая
       7

Весенний контекстный тест с одним бином

0 голосов
/ 27 июня 2018

Каков рекомендуемый способ запуска теста весенней загрузки, когда в контексте настроен только один испытуемый объект.

Если я аннотирую тест с помощью 

@RunWith(SpringRunner.class)
@SpringBootTest(properties = "spring.profiles.active=test")
@ContextConfiguration(classes = MyTestBean.class)

Тогда это похоже на работу - тест проходит, контекст запускается быстро и, кажется, содержит только тот бин, который я хочу. Однако это похоже на неправильное использование аннотации @ContextConfiguration(classes = MyTestBean.class). Если я правильно понимаю, класс, на который я ссылаюсь, должен быть классом Configuration, а не обычным компонентом службы поддержки Spring или компонентом, например.

Это верно? Или это действительно верный способ достижения этой цели? Я знаю, что есть более сложные примеры, такие как org.springframework.boot.test.autoconfigure.json.JsonTest, в которых для управления контекстом используется @TypeExcludeFilters(JsonExcludeFilter.class), но для моего варианта использования это кажется излишним. Я просто хочу контекст с моим единственным бобом.

Разъяснение

Я знаю, что я могу просто создать один bean-компонент, который я тестирую, как POJO без весеннего контекстного теста, и удалить три аннотации, описанные выше. Но в моем конкретном случае использования я на самом деле полагаюсь на некоторые настройки, применяемые к контексту с помощью настроек в файле application-test.properties - вот почему я сделал этот тест Spring Boot с набором профилей. С моей точки зрения, это не простой модульный тест отдельного класса в изоляции конфигурации контекста пружины - тест зависит от определенной применяемой конфигурации (которая в настоящее время обеспечивается свойствами приложения весенней загрузки). Я действительно могу просто протестировать компоненты как POJO, создав новый экземпляр вне контекста Spring. Я использую конструкторское внедрение, упрощающее предоставление необходимых зависимостей, но тест опирается на такие вещи, как уровень журнала (тест фактически делает утверждения для определенных создаваемых журналов), который требует, чтобы уровень журнала был установлен правильно (что в настоящее время выполняется с помощью logging.level.com.example=DEBUG в файле свойств, который устанавливает контекст пружины).

Ответы [ 2 ]

0 голосов
/ 27 июня 2018

Для начала, сначала прочитайте документацию (например, JavaDoc, ссылка на которую приведена ниже в этом ответе), это рекомендуемая рекомендация, поскольку она уже отвечает на ваш вопрос.

Если я правильно понимаю, класс, на который я ссылаюсь, должен быть класс Configuration, а не обычный сервисный боб или компонент например.

Это верно?

Нет, это не совсем правильно.

Классы, предоставляемые @ContextConfiguration, являются , как правило, @Configuration классами, но это не обязательно.

Вот выдержка из JavaDoc для @ContextConfiguration:

Аннотированные классы

Термин «аннотированный класс» может относиться к любому из следующего.

  • Класс, помеченный @Configuration
  • Компонент (то есть класс, отмеченный @Component, @Service, @Repository и т. Д.)
  • JSR-330-совместимый класс, аннотированный javax.inject аннотациями
  • Любой другой класс, который содержит @Bean -методы

Таким образом, вы можете передать любой «аннотированный класс» на @ContextConfiguration.

Или это действительно верный способ достижения этой цели?

Это действительно верный способ достижения этой цели; однако также немного необычно загружать ApplicationContext, который содержит один пользовательский компонент.

С уважением,

Сэм ( автор Spring TestContext Framework )

0 голосов
/ 27 июня 2018

Это определенно разумная и нормальная вещь - тестировать только один класс в модульном тесте.

Нет проблем с включением только одного компонента в ваш тестовый контекст. Действительно, @Configuration - это (как правило) просто набор бобов. Вы можете гипотетически создать класс @Configuration только с помощью MyTestBean, но это действительно будет ненужным, поскольку вы можете выполнить то же самое, перечислив свои контекстные компоненты с помощью @ContextConfiguration#classes.

Однако я хочу отметить, что для тестирования только одного компонента в истинном модульном тесте наилучшая практика в идеале заключается в настройке компонента через конструктор и тестировании класса таким образом. Это ключевая причина, по которой ребята из Spring рекомендуют использовать конструктор вместо внедрения свойств. См. Раздел DI на основе конструктора или сеттера этой статьи , Комментарий Оливера Гирке (то есть глава проекта Spring Data) и Google для получения дополнительной информации. Это, вероятно, причина, по которой у вас возникает странное чувство при настройке контекста для одного компонента!

...