#spring #spring-boot #mockito #spring-boot-test
#spring #spring-загрузка #mockito #spring-boot-test
Вопрос:
Наш проект переходит на SpringBoot 2 (с использованием spring-starter-test) и Mockito 3.x . В интеграционных тестах я преобразовал компоненты из @Mock аннотации в @MockBean аннотацию, удалил @InjectMocks там, где это было не нужно, а также MockitoAnnotations.initMocks(this) [в любом случае не уверен, имеет ли это значение] Когда я запускаю тестовый класс по отдельности (содержащий несколько методов тестирования), он выполняется успешно. При запуске всего набора тестов (3k тестов) я начинаю получать сообщение об ошибке
java.lang.IllegalStateException: Failed to load ApplicationContext
at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:132)
at org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:123)
at org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener.postProcessFields(MockitoTestExecutionListener.java:95)
at org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener.injectFields(MockitoTestExecutionListener.java:79)
at org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener.prepareTestInstance(MockitoTestExecutionListener.java:54)
at org.springframework.test.context.TestContextManager.prepareTestInstance(TestContextManager.java:244)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.createTest(SpringJUnit4ClassRunner.java:227)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner$1.runReflectiveCall(SpringJUnit4ClassRunner.java:289)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.methodBlock(SpringJUnit4ClassRunner.java:291)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:246)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.runChild(SpringJUnit4ClassRunner.java:97)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.springframework.test.context.junit4.statements.RunBeforeTestClassCallbacks.evaluate(RunBeforeTestClassCallbacks.java:61)
at org.springframework.test.context.junit4.statements.RunAfterTestClassCallbacks.evaluate(RunAfterTestClassCallbacks.java:70)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.run(SpringJUnit4ClassRunner.java:190)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at jdk.internal.reflect.GeneratedMethodAccessor1601.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:33)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:94)
at com.sun.proxy.$Proxy5.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:119)
at jdk.internal.reflect.GeneratedMethodAccessor1600.invoke(Unknown Source)
at java.base/jdk.internal.reflect..invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:36)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:182)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:164)
at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:414)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:56)
at java.base/java.lang.Thread.run(Thread.java:834)
Вызвано: org.springframework.beans.factory.Исключение BeanDefinitionStoreException: не удалось проанализировать класс конфигурации [etc.VerificationDao $MockitoMock $ 1412655972]; вложенным исключением является java.io.FileNotFoundException: ресурс пути к классу [etc / service /etc / etc /VerificationDao $MockitoMock $1412655972.class ] не может быть открыт, поскольку он не существует
в org.springframework.context.annotation.ConfigurationClassParser.parse(ConfigurationClassParser.java:188)
в org.springframework.context.annotation.ConfigurationClassPostProcessor.processConfigBeanDefinitions(ConfigurationClassPostProcessor.java:319)
в org.springframework.context.annotation.ConfigurationClassPostProcessor.postProcessBeanDefinitionRegistry(ConfigurationClassPostProcessor.java:236)
в org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanDefinitionRegistryPostProcessors(PostProcessorRegistrationDelegate.java:280)
в org.springframework.context.support.PostProcessorRegistrationDelegate.invokeBeanFactoryPostProcessors(PostProcessorRegistrationDelegate.java:96)
в org.springframework.context.support.AbstractApplicationContext.invokeBeanFactoryPostProcessors(AbstractApplicationContext.java:707)
в org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApp)
// Базовый тест расширяется Spring4Runner.class и используя context.xml публичный класс NewServiceTest расширяет базовый тест {
@Autowired
@Qualifier('newServiceV1')
NewServiceV1 newService!;
@MockBean
StartServiceImpl startServiceMock
@Autowired
ScoresService scoresService
@Autowired
StartService startService
@Autowired
ProductV2 productV2
@MockBean
VerificationDao verificationDaoMock;
@Before
public void setUp() {
setMock(startServiceMock)// will have some mock doAnswer etc
}
По какой-то причине к макетам получают доступ перед созданием или что-то еще в целом? Любая помощь будет оценена. Занимаюсь этим уже день или около того.
Обновление: каким-то образом макеты появляются как один из классов конфигурации, которые пытается загрузить Spring. По какой-то причине они не очищаются / сбрасываются. Это происходит не во всех комбинациях тестовых примеров.
Комментарии:
1. Трассировка стека содержит странный путь «/ service / etc / etc / VerificationDao», есть ли что-нибудь необычное в классе VerificationDao?
2. Это был пример пути, который я вставил в трассировку. Хотя я все еще не очень понимаю, что может происходить, но похоже, что когда я даю @MockBean для класса реализации, а не для интерфейса, Spring пытается настроить 2 компонента, один из которых типа Mockito, а другой — обычный компонент (который был определен как компонент)
3. Лучше всего было бы создать минимальный тестовый проект в GitHub, который люди могли бы попробовать и начать работать.
4. Да, это был бы более простой способ, но поскольку у нас так много тестовых примеров, которые нуждаются в миграции, он может работать с одним тестовым примером, но не с набором, что и происходит в настоящее время. Я смог в некоторой степени понять, почему возникает вышеуказанная проблема. Когда Spring находит любой другой тестовый класс (не обязательно тот, который выдает ошибку), и у этого класса есть поле, имитирующее реализацию, а не интерфейс, он пытается найти макет реализации (поскольку это компонент Spring).
5. Я смог пройти мимо этого с помощью @Mock к интерфейсу с определителем вместо класса реализации. Хотя я чувствую, что MockBean очень чувствителен и может вызывать проблемы,