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

Я хотел бы внедрить фиктивный объект 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значение на что-то недопустимое, то при запуске контекста приложения не будет ошибок.

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

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

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

@InjectMocks
private MyTestObject testObject;

@Mock
private MyDependentObject mockedObject;

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

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

У меня есть очень простое решение, использующее 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;
    }
}

Дано:

@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делается по умолчанию)

Если вы используете 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() {
        ....
    }
}

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

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

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

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

В конце концов я нашел ответ на этот вопрос Ронена в своем блоге. Проблема, с которой я столкнулся, связана с тем, что метод 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>

С весны 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>

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

<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> 

Если вы используете 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

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

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

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

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

С весны:

@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;
}

Обновление - новый ответ здесь: 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>

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

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

Я нашел аналогичный ответ как 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 хочет разрешить инъекции из осмеянного боба.

<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

Я использую комбинацию подхода, используемого в ответе Маркусом Т, и простой вспомогательной реализацией, 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методе.

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

Я разработал решение, основанное на предложении Кресимира Несека. Я добавил новую аннотацию @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();
    }

}

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

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

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

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

<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>

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

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