Injetando zombarias de Mockito em um feijão da Primavera

Gostaria de injetar um objeto simulado do Mockito em um bean Spring (3+) para fins de teste de unidade com o JUnit. Atualmente, minhas dependências de bean são injetadas usando a @Autowiredanotação em campos de membros privados.

Eu considerei usar, ReflectionTestUtils.setFieldmas a instância do bean que desejo injetar é na verdade um proxy e, portanto, não declara os campos de membros privados da classe de destino. Não desejo criar um setter público para a dependência, pois modificarei minha interface apenas para fins de teste.

Segui alguns conselhos da comunidade Spring, mas o mock não foi criado e a fiação automática falha:

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

O erro que encontro atualmente é o seguinte:

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

Se eu definir o constructor-argvalor como algo inválido, nenhum erro ocorrerá ao iniciar o contexto do aplicativo.

A melhor maneira é:

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

Atualização
No arquivo de contexto, esta simulação deve ser listada antes que qualquer campo com conexão automática, dependendo dele, seja declarado.

@InjectMocks
private MyTestObject testObject;

@Mock
private MyDependentObject mockedObject;

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

Isso injeta qualquer objeto zombado na classe de teste. Nesse caso, ele injetará mockedObject no testObject. Isso foi mencionado acima, mas aqui está o código.

Eu tenho uma solução muito simples usando o Spring Java Config e o 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;
    }
}

Dado:

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

    // etc
}

Você pode ter a classe que está sendo testada carregada via fiação automática, zombar da dependência do Mockito e usar o ReflectionTestUtils do Spring para injetar a zombaria na classe que está sendo testada.

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

Observe que, antes do Spring 4.3.1, esse método não funcionava com serviços atrás de um proxy (anotado com @Transactional, ou Cacheable, por exemplo). Isso foi corrigido pelo SPR-14050 .

Para versões anteriores, uma solução é desembrulhar o proxy, conforme descrito aqui: A anotação transacional evita que os serviços sejam zombados (que é o que ReflectionTestUtils.setFieldfaz por padrão agora)

Se você estiver usando o Spring Boot 1.4, há uma maneira incrível de fazer isso. Basta usar uma nova marca @SpringBootTestem sua classe e @MockBeanem campo e o Spring Boot criará uma simulação desse tipo e a injetará no contexto (em vez de injetar a original):

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

}

Por outro lado, se você não estiver usando o Spring Boot ou uma versão anterior, precisará trabalhar um pouco mais:

Crie um @Configurationbean que injete suas zombarias no contexto do Spring:

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

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

Usando a @Primaryanotação, você está dizendo ao Spring que esse bean tem prioridade se nenhum qualificador for especificado.

Anote a classe @Profile("useMocks")para controlar quais classes usarão o mock e quais usarão o bean real.

Por fim, em seu teste, ative o userMocksperfil:

@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() {
        ....
    }
}

Se você não quiser usar o mock, mas o bean real, não ative o useMocksperfil:

@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() {
        ....
    }
}

Desde o Mockito 1.8.3@InjectMocks - isso é incrivelmente útil. Meus testes JUnit são @RunWithos MockitoJUnitRunnere eu construo @Mockobjetos que satisfazem todas as dependências da classe que está sendo testada, que são todas injetadas quando o membro privado é anotado @InjectMocks.

I @RunWitha SpringJUnit4Runnerúnica agora para testes de integração.

Observarei que não parece ser capaz de injetar List<T>da mesma maneira que o Spring. Ele procura apenas um objeto Mock que satisfaça o Liste não injeta uma lista de objetos Mock. A solução alternativa para mim foi usar uma @Spylista instanciada manualmente e adicionar manualmente os objetos simulados a essa lista para teste de unidade. Talvez isso tenha sido intencional, porque certamente me forçou a prestar muita atenção ao que estava sendo ridicularizado juntos.

Atualização: Agora existem soluções melhores e mais limpas para esse problema. Por favor, considere as outras respostas primeiro.

Acabei encontrando uma resposta para isso de Ronen em seu blog. O problema que eu estava tendo é devido ao método que Mockito.mock(Class c)declara um tipo de retorno Object. Consequentemente, o Spring não pode inferir o tipo de bean do tipo de retorno do método de fábrica.

A solução de Ronen é criar uma FactoryBeanimplementação que retorne simulações. A FactoryBeaninterface permite que o Spring consulte o tipo de objetos criados pelo bean de fábrica.

Minha definição de bean zombado agora se parece com:

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

A partir do Spring 3.2, isso não é mais um problema. O Spring agora suporta a ligação automática dos resultados de métodos genéricos de fábrica. Consulte a seção "Métodos genéricos de fábrica" ​​nesta postagem do blog: http://spring.io/blog/2012/11/07/spring-framework-3-2-rc1-new-testing-features/ .

O ponto principal é:

No Spring 3.2, tipos de retorno genéricos para métodos de fábrica agora são inferidos corretamente, e a fiação automática por tipo para zombarias deve funcionar conforme o esperado. Como resultado, soluções alternativas personalizadas, como MockitoFactoryBean, EasyMockFactoryBean ou Springockito, provavelmente não são mais necessárias.

O que significa que isso deve funcionar imediatamente:

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

O código abaixo funciona com fiação automática - não é a versão mais curta, mas é útil quando deve funcionar apenas com os jarros de mola / mockito padrão.

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

Se você estiver usando spring> = 3.0 , tente usar a @Configurationanotação Springs para definir parte do contexto do aplicativo

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

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

}

Se você não quiser usar o @ImportResource, isso também pode ser feito ao contrário:

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

Para obter mais informações, consulte spring-framework-reference: Configuração de contêiner baseado em Java

Talvez não seja a solução perfeita, mas costumo não usar a mola para fazer DI para testes de unidade. as dependências de um único bean (a classe em teste) geralmente não são muito complexas, então eu apenas injeto diretamente no código de teste.

Eu posso fazer o seguinte usando o Mockito:

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

Publicando alguns exemplos com base nas abordagens acima

Com primavera:

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

Sem mola:

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

Atualização - nova resposta aqui: https://stackoverflow.com/a/19454282/411229 . Esta resposta se aplica apenas às versões Spring anteriores à 3.2.

Procurei por um tempo uma solução mais definitiva para isso. Esta postagem do blog parece cobrir todas as minhas necessidades e não depende da ordem das declarações do bean. Todo o crédito a Mattias Severson. http://www.jayway.com/2011/11/30/spring-integration-tests-part-i-creating-mock-objects/

Basicamente, implemente um 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;
    }
}

Atualize sua configuração de primavera com o seguinte:

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

Observando o ritmo de desenvolvimento de Springockito e o número de questões em aberto , eu ficaria um pouco preocupado em introduzi-lo na minha pilha de suítes de teste atualmente. O fato de o último lançamento ter sido feito antes do lançamento do Spring 4 traz questões como "É possível integrá-lo facilmente ao Spring 4?". Não sei, porque não tentei. Prefiro a abordagem pura do Spring se eu precisar zombar do Spring bean no teste de integração.

Existe uma opção para falsificar o Spring bean com recursos simples do Spring. Você precisa usar @Primary, @Profilee @ActiveProfilesanotações para ele. Eu escrevi uma postagem no blog sobre o assunto.

Encontrei uma resposta semelhante ao teabot para criar um MockFactory que fornece os zombadores. Usei o exemplo a seguir para criar a fábrica de simulação (já que o link para o narkisr está morto): http://hg.randompage.org/java/src/407e78aa08a0/projects/bookmarking/backend/spring/src/test/java/ org / randompage / bookmarking / backend / testUtils / MocksFactory.java

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

Isso também ajuda a impedir que o Spring queira resolver as injeções do feijão zombado.

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

isto ^ funciona perfeitamente se declarado primeiro / no início do arquivo XML. Mockito 1.9.0 / Primavera 3.0.5

Uso uma combinação da abordagem usada na resposta por Markus T e uma implementação auxiliar simples ImportBeanDefinitionRegistrarque procura uma anotação personalizada ( @MockedBeans) na qual é possível especificar quais classes devem ser ridicularizadas. Acredito que essa abordagem resulta em um teste de unidade conciso com parte do código padrão relacionado à zombaria removida.

Veja como um teste de unidade de amostra se parece com essa abordagem:

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

Para fazer isso acontecer, você precisa definir duas classes auxiliares simples - anotação personalizada ( @MockedBeans) e uma ImportBeanDefinitionRegistrarimplementação customizada . @MockedBeansa definição de anotação precisa ser anotada @Import(CustomImportBeanDefinitionRegistrar.class)e ImportBeanDefinitionRgistrarprecisa incluir definições de beans simulados na configuração em seu registerBeanDefinitionsmétodo.

Se você gosta da abordagem, pode encontrar exemplos de implementações no meu blog .

Eu desenvolvi uma solução baseada na proposta de Kresimir Nesek. Adicionei uma nova anotação @EnableMockedBean para tornar o código um pouco mais limpo e modular.

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

}

Eu escrevi um post explicando isso.

Eu sugeriria migrar seu projeto para o Spring Boot 1.4. Depois disso, você pode usar uma nova anotação @MockBeanpara falsificar suacom.package.Dao

Hoje eu descobri que um contexto de primavera em que eu declara um antes dos grãos Mockito estava falhando ao carregar. Depois de mover APÓS as zombarias, o contexto do aplicativo foi carregado com sucesso. Cuidar :)

Para o registro, todos os meus testes funcionam corretamente, apenas tornando o equipamento inicializado preguiçosamente, por exemplo:

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

Suponho que o raciocínio é o que Mattias explica aqui (na parte inferior do post), que uma solução alternativa está mudando a ordem em que os beans são declarados - a inicialização lenta é "uma espécie de" ter o equipamento declarado no final.

Se você usa Injeção de Controlador, verifique se suas variáveis ​​locais NÃO são "finais"