Инъекция Mockito издевается в бобе Spring


284

Я хотел бы внедрить фиктивный объект Mockito в bean-компонент Spring (3+) для модульного тестирования с помощью JUnit. Мои зависимости bean-компонентов в настоящее время внедряются с использованием @Autowiredаннотации для закрытых полей-членов.

Я рассмотрел использование, ReflectionTestUtils.setFieldно экземпляр компонента, который я хочу внедрить, на самом деле является прокси и, следовательно, не объявляет поля закрытого члена целевого класса. Я не хочу создавать общедоступный установщик для зависимости, так как тогда я буду модифицировать свой интерфейс исключительно для целей тестирования.

Я следовал некоторым советам, данным сообществом Spring, но макет не создается, и автоматическое подключение не работает:

<bean id="dao" class="org.mockito.Mockito" factory-method="mock">
    <constructor-arg value="com.package.Dao" />
</bean>

Ошибка, с которой я сейчас сталкиваюсь, такова:

...
Caused by: org...NoSuchBeanDefinitionException:
    No matching bean of type [com.package.Dao] found for dependency:
    expected at least 1 bean which qualifies as autowire candidate for this dependency.
    Dependency annotations: {
        @org...Autowired(required=true),
        @org...Qualifier(value=dao)
    }
at org...DefaultListableBeanFactory.raiseNoSuchBeanDefinitionException(D...y.java:901)
at org...DefaultListableBeanFactory.doResolveDependency(D...y.java:770)

Если я установил constructor-argзначение на что-то недопустимое, то при запуске контекста приложения не будет ошибок.


4
Пожалуйста, взгляните на это крошечное маленькое существо: bitbucket.org/kubek2k/springockito/wiki/Home
kubek2k

Это очень чистый подход - мне это нравится!
чайник

2
Вы были у меня на Springockito-аннотации.
yihtserns


2
Для тех, кто использует Spring 4. *, по состоянию на январь 2015 года он не работает с последней версией весеннего мокито, и проект, по-видимому, неактивен.
Мурали

Ответы:


130

Лучший способ это:

<bean id="dao" class="org.mockito.Mockito" factory-method="mock"> 
    <constructor-arg value="com.package.Dao" /> 
</bean> 

Обновление
В файле контекста этот макет должен быть указан до того, как будет объявлено любое поле с автопроводкой, в зависимости от того, какое оно будет.


Я получаю сообщение об ошибке: «Ошибка создания компонента с именем« mockito »: определение компонента является абстрактным»
tttppp

4
@amra: весна не определяет тип возвращаемого объекта в этом случае ... stackoverflow.com/q/6976421/306488
Лисак,

7
Не знаю, почему за этот ответ так много проголосовало, что полученный бин не может быть автоматически подключен, потому что он имеет неправильный тип.
Азероль

4
Он может быть подключен автоматически, если он указан первым в файле контекста (до того, как будут объявлены все поля с автоматическим подключением, которые будут зависеть от него.)
Ryan Walls

3
С весны 3.2 порядок бобов больше не имеет значения. См. Раздел «Общие фабричные методы» в этом сообщении в блоге: spring.io/blog/2012/11/07/…
Райан Уоллс

110
@InjectMocks
private MyTestObject testObject;

@Mock
private MyDependentObject mockedObject;

@Before
public void setup() {
        MockitoAnnotations.initMocks(this);
}

Это добавит любые проверенные объекты в тестовый класс. В этом случае он вставит mockedObject в testObject. Это было упомянуто выше, но вот код.


1
Как мне заглушить конкретный метод mockedObject?
Джим Холден

@Teinacher when (mockedObject.execute) .thenReturn (objToReturn); Вы можете поместить это либо в метод before, либо в метод test.
Chaostheory

40
К вашему сведению: этот подход не будет работать, если я хочу частичную автопроводку и частичную насмешку в MyTestObject.
Ракша

9
Я не знаю, почему за это не проголосовали выше. Если я увижу больше ответов, содержащих XML, я собираюсь бросить.
MarkOfHall

3
Почему бы тебе не использовать Mockito.spy(...)это mockedObjectвместо этого? А затем используйте when(mockedObject.execute).thenReturn(objToReturn)или doReturn(objToReturn).when(mockedObject).execute(). Второй не вызывает реальный метод. Вы также можете проверить Mockito.doCallRealMethod()документацию
Томаш Прзыбыльски

63

У меня есть очень простое решение, использующее Spring Java Config и Mockito:

@Configuration
public class TestConfig {

    @Mock BeanA beanA;
    @Mock BeanB beanB;

    public TestConfig() {
        MockitoAnnotations.initMocks(this); //This is a key
    }

    //You basically generate getters and add @Bean annotation everywhere
    @Bean
    public BeanA getBeanA() {
        return beanA;
    }

    @Bean
    public BeanB getBeanB() {
        return beanB;
    }
}

4
По какой-то причине при таком подходе Spring все равно пытается создать реальный боб (вместо насмешки) и задыхается от этого ... Что я делаю не так?
Даниэль Грушчик

1
У меня такая же проблема
Коробко Алексей

3
Не весна, а скорее mockito пытается создать настоящий боб, если вы издеваетесь над классом. Если у вас есть какие-либо bean-компоненты, которые нужно проверять в тестах, они должны быть реализациями интерфейса и внедряться через этот интерфейс. Если вы затем смоделируете интерфейс (а не класс), mockito не будет пытаться создать экземпляр этого класса.
Даниэль Грущик

7
Какой смысл? Зачем добавлять аннотированные поля и конструктор с initMocks? Почему не только return Mockito.mock(BeanA.class)в getBeanA? Так проще и меньше кода. Чего мне не хватает?
Олег

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

48

Дано:

@Service
public class MyService {
    @Autowired
    private MyDAO myDAO;

    // etc
}

Вы можете загрузить тестируемый класс с помощью автоматической разводки, смоделировать зависимость с помощью Mockito, а затем использовать Spring ReflectionTestUtils, чтобы вставить макет в тестируемый класс.

@ContextConfiguration(classes = { MvcConfiguration.class })
@RunWith(SpringJUnit4ClassRunner.class)
public class MyServiceTest {
    @Autowired
    private MyService myService;

    private MyDAO myDAOMock;

    @Before
    public void before() {
        myDAOMock = Mockito.mock(MyDAO.class);
        ReflectionTestUtils.setField(myService, "myDAO", myDAOMock);
    }

    // etc
}

Обратите внимание, что до Spring 4.3.1 этот метод не работал со службами за прокси-сервером (с комментариями @Transactionalили Cacheable, например). Это было исправлено SPR-14050 .

Для более ранних версий решение состоит в том, чтобы развернуть прокси-сервер, как описано здесь: Транзакционная аннотация предотвращает мошенничество с сервисами (что сейчас и ReflectionTestUtils.setFieldделается по умолчанию)


Дважды @RunWith (SpringJUnit4ClassRunner.class) и я использую разные аннотации для тестового класса (один и тот же бегун), но этот подход работает для меня, спасибо.
user1317422

1
Меня очень вдохновило «Обратите внимание, что до Spring 4.3.1 этот метод не работал со службами за прокси-сервером (аннотированными, например, @Transactional или Cacheable). Это было исправлено SPR-14050». Я просто столкнулся с этой проблемой точно и не получил никакой подсказки, пока не заметил эти слова. БОЛЬШОЕ СПАСИБО!
snowfox

1
Это решение работает, когда вы подключили весь контекст приложения и, для целей тестирования, хотите внедрить макет в случайный компонент в вашем контексте. Я использовал этот ответ, чтобы смоделировать симулированный клиентский бин, чтобы избежать вызовов REST для других модулей в тесте модуля. Я только получил аннотацию InjectMock для работы, когда вы внедряете макеты в bean-компоненте, который вы собираетесь тестировать, а не в bean-компоненте, созданном в Spring Application Configuration.
Андреас Лундгрен

1
Почти целый день, пытаясь заставить @MockBean работать без сброса контекста, я натолкнулся на этот камень. Именно то, что мне было нужно, ура.
Мэтт Р

Работает, хотя имейте в виду, что замененное поле может не сбрасываться из-за кэширования, и некоторые несвязанные тесты могут сломаться. Например, в моем тесте я заменил кодировщик паролей на фиктивный, и несколько других тестов не сработали из-за ошибок авторизации.
alextsil

36

Если вы используете Spring Boot 1.4, у вас есть отличный способ сделать это. Просто используйте новый бренд @SpringBootTestв своем классе и @MockBeanна поле, и Spring Boot создаст макет этого типа и вставит его в контекст (вместо внедрения оригинального):

@RunWith(SpringRunner.class)
@SpringBootTest
public class MyTests {

    @MockBean
    private RemoteService remoteService;

    @Autowired
    private Reverser reverser;

    @Test
    public void exampleTest() {
        // RemoteService has been injected into the reverser bean
        given(this.remoteService.someCall()).willReturn("mock");
        String reverse = reverser.reverseSomeCall();
        assertThat(reverse).isEqualTo("kcom");
    }

}

С другой стороны, если вы не используете Spring Boot или используете предыдущую версию, вам придется проделать немного больше работы:

Создайте @Configurationbean-компонент, который вставляет ваши макеты в контекст Spring:

@Configuration
@Profile("useMocks")
public class MockConfigurer {

    @Bean
    @Primary
    public MyBean myBeanSpy() {
        return mock(MyBean.class);
    }
}

Используя @Primaryаннотацию, вы говорите Spring, что этот бин имеет приоритет, если не указан спецификатор.

Убедитесь, что вы аннотировали класс @Profile("useMocks"), чтобы контролировать, какие классы будут использовать макет, а какие - настоящий бин.

Наконец, в вашем тесте активируйте userMocksпрофиль:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = {Application.class})
@WebIntegrationTest
@ActiveProfiles(profiles={"useMocks"})
public class YourIntegrationTestIT {

    @Inject
    private MyBean myBean; //It will be the mock!


    @Test
    public void test() {
        ....
    }
}

Если вы не хотите использовать макет, а настоящий боб, просто не активируйте useMocksпрофиль:

@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes = {Application.class})
@WebIntegrationTest
public class AnotherIntegrationTestIT {

    @Inject
    private MyBean myBean; //It will be the real implementation!


    @Test
    public void test() {
        ....
    }
}

5
Этот ответ должен идти к началу - поддержка @MockBean в весенней загрузке также может использоваться без весенней загрузки. Вы можете использовать его только в модульных тестах, чтобы он работал для всех весенних приложений!
постельное белье

2
@Профильную аннотацию вы также можете установить в методе определения компонента, чтобы избежать создания отдельного класса конфигурации
marcin

Отличный ответ! Я сделал несколько изменений, чтобы он работал с моей старой школой web.xmlи настройкой AnnotationConfigWebApplicationContext. Пришлось использовать @WebAppConfigurationвместо @WebIntegrationTestи @ContextHierarchyс @ContextConfigurationвместо @SpringApplicationConfiguration.
UTF_or_Death

Мне пришлось добавить @Primaryаннотацию для моего случая, так как внутри a произошел сбой вызова, @PostConstructкоторый я хотел высказать, но @PostConstructbean-компонент был создан перед моей имитацией, поэтому он не использовал mock (пока я не добавил @Primary).
helleye

19

Начиная с версии 1.8.3 Mockito @InjectMocks- это невероятно полезно. Мои тесты JUnit - @RunWithэто объекты, MockitoJUnitRunnerи я создаю @Mockобъекты, которые удовлетворяют всем зависимостям для тестируемого класса, и все они внедряются, когда аннотируется закрытый член @InjectMocks.

Я для интеграции тестов только сейчас.@RunWithSpringJUnit4Runner

Отмечу, что он, похоже, не способен впрыскивать так List<T>же, как Spring. Он ищет только объект Mock, который удовлетворяет List, и не будет вводить список объектов Mock. Обходной путь для меня состоял в том, чтобы использовать @Spyсписок, созданный вручную, и вручную добавить фиктивные объекты в этот список для модульного тестирования. Возможно, это было сделано намеренно, потому что это, безусловно, заставило меня обратить пристальное внимание на то, что насмехалось вместе.


Да, это лучший способ. Спрингокито на самом деле не вводит насмешки по любой причине в моем случае.
Chaostheory

13

Обновление: теперь есть лучшие, более чистые решения этой проблемы. Пожалуйста, рассмотрите другие ответы в первую очередь.

В конце концов я нашел ответ на этот вопрос Ронена в своем блоге. Проблема, с которой я столкнулся, связана с тем, что метод Mockito.mock(Class c)объявляет тип возвращаемого значения Object. Следовательно, Spring не может определить тип компонента из возвращаемого фабричным методом.

Решение Ронена состоит в том, чтобы создать FactoryBeanреализацию, которая возвращает макеты. FactoryBeanИнтерфейс позволяет Spring запрашивать тип объектов , созданных на заводе боба.

Моё определение бобового бина теперь выглядит так:

<bean id="mockDaoFactory" name="dao" class="com.package.test.MocksFactory">
    <property name="type" value="com.package.Dao" />
</bean>

1
Обновлена ​​ссылка на решение Ронена
Джефф Мартин,

Я не понимаю, что у фабричного метода есть тип возвращаемого значения Object ... Но решение amra имеет общий тип возвращаемого значения, поэтому Spring должен его распознать ... Но решение amra у меня не работает
lisak

Ни в этом решении, Spring не определяет тип компонента, возвращаемого из factoryBean, следовательно, нет соответствующего компонента типа [com.package.Dao] ...
lisak


Эта ссылка на самом деле все еще работает: javadevelopmentforthemasses.blogspot.com/2008/07/… Просто отключите перенаправление ссылок в вашем браузере, и вы увидите его, вместо того, чтобы заставлять смотреть 404 в его новом блоге.
приблизительно

12

С весны 3.2 это больше не проблема. Spring теперь поддерживает Autowiring результатов универсальных фабричных методов. См. Раздел «Общие фабричные методы» в этом сообщении блога: http://spring.io/blog/2012/11/07/spring-framework-3-2-rc1-new-testing-features/ .

Ключевым моментом является:

В Spring 3.2 родовые возвращаемые типы для фабричных методов теперь правильно выводятся, и автоматическая разводка по типам для имитаций должна работать как положено. В результате пользовательские обходные пути, такие как MockitoFactoryBean, EasyMockFactoryBean или Springockito, больше не нужны.

Что означает, что это должно работать из коробки:

<bean id="dao" class="org.mockito.Mockito" factory-method="mock">
    <constructor-arg value="com.package.Dao" />
</bean>

9

Приведенный ниже код работает с автопроводкой - это не самая короткая версия, но полезная, когда она должна работать только со стандартными банками с пружиной / мокито.

<bean id="dao" class="org.springframework.aop.framework.ProxyFactoryBean">
   <property name="target"> <bean class="org.mockito.Mockito" factory-method="mock"> <constructor-arg value="com.package.Dao" /> </bean> </property>
   <property name="proxyInterfaces"> <value>com.package.Dao</value> </property>
</bean> 

Работал на меня. Мне пришлось развернуть прокси в моем тесте, чтобы проверить его, как описано здесь: forum.spring.io/forum/spring-projects/aop/…
Holgzn

9

Если вы используете spring> = 3.0 , попробуйте использовать @Configurationаннотацию Springs, чтобы определить часть контекста приложения.

@Configuration
@ImportResource("com/blah/blurk/rest-of-config.xml")
public class DaoTestConfiguration {

    @Bean
    public ApplicationService applicationService() {
        return mock(ApplicationService.class);
    }

}

Если вы не хотите использовать @ImportResource, это можно сделать и наоборот:

<beans>
    <!-- rest of your config -->

    <!-- the container recognize this as a Configuration and adds it's beans 
         to the container -->
    <bean class="com.package.DaoTestConfiguration"/>
</beans>

Для получения дополнительной информации взгляните на spring-framework-reference: конфигурация контейнера на основе Java


Хороший. Я использовал это, когда тестируемый тест @Autowired в реальном тестовом случае.
enkor

8

Возможно, не идеальное решение, но я склонен не использовать пружину, чтобы делать DI для модульных тестов. зависимости для одного компонента (тестируемого класса) обычно не слишком сложны, поэтому я просто делаю инъекцию непосредственно в тестовом коде.


3
Я понимаю ваш подход. Тем не менее, я нахожусь в этой ситуации на большой базе устаревшего кода, которая не может легко это сделать - пока.
teabot

1
Я обнаружил, что комбинирование Mockito / Spring очень полезно, когда мне нужно протестировать код, который сильно зависит от аспектов Spring / AOP (например, при тестировании правил безопасности Spring). Хотя совершенно справедливо утверждать, что такие тесты должны быть интеграционными.
Ларс Такманн

@Lars - согласился - то же самое можно сказать о тестах, с которыми я имею дело.
teabot

7

Я могу сделать следующее, используя Mockito:

<bean id="stateMachine" class="org.mockito.Mockito" factory-method="mock">
    <constructor-arg value="com.abcd.StateMachine"/>
</bean>

1
Спасибо за ответ @ Александр. Могу я спросить: правильно ли он подключен? Если да, то какие версии Spring / Mockito вы используете?
teabot

6

Опубликовать несколько примеров на основе вышеуказанных подходов

С весны:

@ContextConfiguration(locations = { "classpath:context.xml" })
@RunWith(SpringJUnit4ClassRunner.class)
public class TestServiceTest {
    @InjectMocks
    private TestService testService;
    @Mock
    private TestService2 testService2;
}

Без весны:

@RunWith(MockitoJUnitRunner.class)
public class TestServiceTest {
    @InjectMocks
    private TestService testService = new TestServiceImpl();
    @Mock
    private TestService2 testService2;
}

2

Обновление - новый ответ здесь: https://stackoverflow.com/a/19454282/411229 . Этот ответ применим только к тем версиям Spring до 3.2.

Некоторое время я искал более определенное решение для этого. Этот пост в блоге, кажется, покрывает все мои потребности и не зависит от упорядочения объявлений бобов. Все заслуги Маттиаса Северсона. http://www.jayway.com/2011/11/30/spring-integration-tests-part-i-creating-mock-objects/

В основном, реализовать FactoryBean

package com.jayway.springmock;

import org.mockito.Mockito;
import org.springframework.beans.factory.FactoryBean;

/**
 * A {@link FactoryBean} for creating mocked beans based on Mockito so that they 
 * can be {@link @Autowired} into Spring test configurations.
 *
 * @author Mattias Severson, Jayway
 *
 * @see FactoryBean
 * @see org.mockito.Mockito
 */
public class MockitoFactoryBean<T> implements FactoryBean<T> {

    private Class<T> classToBeMocked;

    /**
     * Creates a Mockito mock instance of the provided class.
     * @param classToBeMocked The class to be mocked.
     */
    public MockitoFactoryBean(Class<T> classToBeMocked) {
        this.classToBeMocked = classToBeMocked;
    }

    @Override
    public T getObject() throws Exception {
        return Mockito.mock(classToBeMocked);
    }

    @Override
    public Class<?> getObjectType() {
        return classToBeMocked;
    }

    @Override
    public boolean isSingleton() {
        return true;
    }
}

Затем обновите ваш весенний конфиг следующим образом:

<beans...>
    <context:component-scan base-package="com.jayway.example"/>

    <bean id="someDependencyMock" class="com.jayway.springmock.MockitoFactoryBean">
        <constructor-arg name="classToBeMocked" value="com.jayway.example.SomeDependency" />
    </bean>
</beans>

2

Глядя на темп развития Springockito и количество открытых вопросов , я бы немного волновался о том, чтобы внедрить его в свой набор тестовых наборов. Тот факт, что последний выпуск был сделан до выпуска Spring 4, поднимает такие вопросы, как «Возможно ли легко интегрировать его с Spring 4?». Я не знаю, потому что я не пробовал это. Я предпочитаю чистый подход Spring, если мне нужно смоделировать Spring bean в интеграционном тесте.

Существует возможность подделать Spring bean с помощью простых функций Spring. Вам нужно использовать @Primary, @Profileи @ActiveProfilesаннотацию к нему. Я написал сообщение в блоге на эту тему.


1

Я нашел аналогичный ответ как teabot, чтобы создать MockFactory, который предоставляет макеты. Я использовал следующий пример для создания фиктивной фабрики (поскольку ссылка на narkisr мертва): http://hg.randompage.org/java/src/407e78aa08a0/projects/bookmarking/backend/spring/src/test/java/ орг / Randompage / закладки / бэкенд / testUtils / MocksFactory.java

<bean id="someFacade" class="nl.package.test.MockFactory">
    <property name="type" value="nl.package.someFacade"/>
</bean>

Это также помогает предотвратить то, что Spring хочет разрешить инъекции из осмеянного боба.


1
<bean id="mockDaoFactory" name="dao" class="com.package.test.MocksFactory">
    <property name="type" value="com.package.Dao" />
</bean>

это ^ отлично работает, если объявлено первым / рано в файле XML. Mockito 1.9.0 / Spring 3.0.5


1

Я использую комбинацию подхода, используемого в ответе Маркусом Т, и простой вспомогательной реализацией, ImportBeanDefinitionRegistrarкоторая ищет пользовательскую аннотацию ( @MockedBeans), в которой можно указать, какие классы должны быть смоделированы. Я полагаю, что этот подход приводит к краткому модульному тестированию с удалением некоторого стандартного кода, связанного с имитацией.

Вот как выглядит примерный модульный тест с таким подходом:

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration(loader=AnnotationConfigContextLoader.class)
public class ExampleServiceIntegrationTest {

    //our service under test, with mocked dependencies injected
    @Autowired
    ExampleService exampleService;

    //we can autowire mocked beans if we need to used them in tests
    @Autowired
    DependencyBeanA dependencyBeanA;

    @Test
    public void testSomeMethod() {
        ...
        exampleService.someMethod();
        ...
        verify(dependencyBeanA, times(1)).someDependencyMethod();
    }

    /**
     * Inner class configuration object for this test. Spring will read it thanks to
     * @ContextConfiguration(loader=AnnotationConfigContextLoader.class) annotation on the test class.
     */
    @Configuration
    @Import(TestAppConfig.class) //TestAppConfig may contain some common integration testing configuration
    @MockedBeans({DependencyBeanA.class, DependencyBeanB.class, AnotherDependency.class}) //Beans to be mocked
    static class ContextConfiguration {

        @Bean
        public ExampleService exampleService() {
            return new ExampleService(); //our service under test
        }
    }
}

Чтобы это произошло, вам нужно определить два простых вспомогательных класса - пользовательскую аннотацию ( @MockedBeans) и пользовательскую ImportBeanDefinitionRegistrarреализацию. @MockedBeansОпределение аннотации должно быть аннотировано, @Import(CustomImportBeanDefinitionRegistrar.class)и ImportBeanDefinitionRgistrarнеобходимо добавить определения фиктивных бинов к конфигурации в его registerBeanDefinitionsметоде.

Если вам нравится подход, вы можете найти примеры реализации в моем блоге .


1

Я разработал решение, основанное на предложении Кресимира Несека. Я добавил новую аннотацию @EnableMockedBean , чтобы сделать код немного чище и модульным.

@EnableMockedBean
@SpringBootApplication
@RunWith(SpringJUnit4ClassRunner.class)
@SpringApplicationConfiguration(classes=MockedBeanTest.class)
public class MockedBeanTest {

    @MockedBean
    private HelloWorldService helloWorldService;

    @Autowired
    private MiddleComponent middleComponent;

    @Test
    public void helloWorldIsCalledOnlyOnce() {

        middleComponent.getHelloMessage();

        // THEN HelloWorldService is called only once
        verify(helloWorldService, times(1)).getHelloMessage();
    }

}

Я написал пост, объясняющий это.


1

Я бы предложил перенести ваш проект на Spring Boot 1.4. После этого вы можете использовать новую аннотацию, @MockBeanчтобы подделатьcom.package.Dao


0

Сегодня я обнаружил, что весенний контекст, в котором я объявил перед бобами Mockito, не загружался. После перемещения ПОСЛЕ макетов контекст приложения был успешно загружен. Береги себя :)


1
Там чего-то не хватает. 8-) Что вы переехали после издевательств?
Ганс-Петер Стёрр

0

Для справки, все мои тесты корректно работают, просто делая инициализацию прибора отложенной, например:

<bean id="fixture"
      class="it.tidalwave.northernwind.rca.embeddedserver.impl.DefaultEmbeddedServer"
      lazy-init="true" /> <!-- To solve Mockito + Spring problems -->

<bean class="it.tidalwave.messagebus.aspect.spring.MessageBusAdapterFactory" />

<bean id="applicationMessageBus"
      class="org.mockito.Mockito" factory-method="mock">
    <constructor-arg value="it.tidalwave.messagebus.MessageBus" />
</bean>

<bean class="org.mockito.Mockito" factory-method="mock">
    <constructor-arg value="javax.servlet.ServletContext" />
</bean>

Я полагаю, что обоснование - это то, что Маттиас объясняет здесь (внизу поста), что обходной путь изменяет порядок объявления бинов - ленивая инициализация - это «своего рода» объявление объекта в конце.


-1

Если вы используете Controller Injection, убедитесь, что ваши локальные переменные НЕ являются «окончательными»

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.