Inyectar simulacros de Mockito en un frijol Spring

Me gustaría inyectar un objeto simulado Mockito en un bean Spring (3+) para realizar pruebas unitarias con JUnit. Actualmente, mis dependencias de bean se inyectan mediante la @Autowiredanotación en campos de miembros privados.

He considerado usar, ReflectionTestUtils.setFieldpero la instancia de bean que deseo inyectar es en realidad un proxy y, por lo tanto, no declara los campos de miembros privados de la clase de destino. No deseo crear un setter público para la dependencia, ya que luego modificaré mi interfaz con el único fin de realizar pruebas.

He seguido algunos consejos dados por la comunidad de Spring, pero el simulacro no se crea y el cableado automático falla:

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

El error que encuentro actualmente es el siguiente:

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

Si configuro el constructor-argvalor en algo no válido, no se produce ningún error al iniciar el contexto de la aplicación.

La mejor manera es:

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

Actualización
En el archivo de contexto, este simulacro debe aparecer antes de que se declare cualquier campo con conexión automática, según se declare.

@InjectMocks
private MyTestObject testObject;

@Mock
private MyDependentObject mockedObject;

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

Esto inyectará cualquier objeto burlado en la clase de prueba. En este caso, inyectará mockedObject en testObject. Esto se mencionó anteriormente, pero aquí está el código.

Tengo una solución muy simple usando Spring Java Config y 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
}

Puede cargar la clase que se está probando mediante el cableado automático, simular la dependencia con Mockito y luego usar Spring's ReflectionTestUtils para inyectar el simulacro en la clase que se está probando.

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

Tenga en cuenta que antes de Spring 4.3.1, este método no funcionará con servicios detrás de un proxy (anotado con @Transactional, o Cacheable, por ejemplo). Esto ha sido arreglado por SPR-14050 .

Para versiones anteriores, una solución es desenvolver el proxy, como se describe allí: la anotación transaccional evita la burla de los servicios (que es lo que ReflectionTestUtils.setFieldhace ahora por defecto)

Si está utilizando Spring Boot 1.4, tiene una forma increíble de hacerlo. Simplemente use una nueva marca @SpringBootTesten su clase y @MockBeanen el campo y Spring Boot creará un simulacro de este tipo y lo inyectará en el contexto (en lugar de inyectar el 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 otro lado, si no está utilizando Spring Boot o está utilizando una versión anterior, tendrá que trabajar un poco más:

Crea un @Configurationbean que inyecte tus simulacros en el contexto de Spring:

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

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

Usando la @Primaryanotación, le está diciendo a Spring que este bean tiene prioridad si no se especifica ningún calificador.

Asegúrese de anotar la clase con el @Profile("useMocks")fin de controlar qué clases usarán el simulacro y cuáles usarán el bean real.

Finalmente, en su prueba, active el 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() {
        ....
    }
}

Si no desea utilizar el simulacro sino el bean real, simplemente no active el 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 1.8.3 Mockito lo ha hecho @InjectMocks, esto es increíblemente útil. Mis pruebas JUnit son @RunWithel MockitoJUnitRunnery construir @Mockobjetos que satisfacen todas las dependencias de la clase siendo probados, los cuales están inyectados cuando el miembro privado se anota con @InjectMocks.

Yo @RunWithla SpringJUnit4Runnerde las pruebas de integración sólo ahora.

Notaré que no parece ser capaz de inyectar List<T>de la misma manera que Spring. Solo busca un objeto Mock que satisfaga el List, y no inyectará una lista de objetos Mock. La solución para mí fue utilizar una @Spylista de instancia manual en contra y agregar manualmente los objetos simulados a esa lista para pruebas unitarias. Tal vez eso fue intencional, porque ciertamente me obligó a prestar mucha atención a lo que se estaba burlando juntos.

Actualización: ahora hay soluciones mejores y más limpias para este problema. Por favor considere las otras respuestas primero.

Finalmente encontré una respuesta a esto por parte de ronen en su blog. El problema que estaba teniendo se debe al método que Mockito.mock(Class c)declara un tipo de retorno de Object. En consecuencia, Spring no puede inferir el tipo de bean del tipo de retorno del método de fábrica.

La solución de Ronen es crear una FactoryBeanimplementación que devuelva simulacros. La FactoryBeaninterfaz permite a Spring consultar el tipo de objetos creados por el bean de fábrica.

Mi definición de frijol burlado ahora se ve así:

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

A partir de la primavera 3.2, esto ya no es un problema. Spring ahora admite el Autowiring de los resultados de los métodos genéricos de fábrica. Consulte la sección titulada "Métodos genéricos de fábrica" ​​en esta publicación de blog: http://spring.io/blog/2012/11/07/spring-framework-3-2-rc1-new-testing-features/ .

El punto clave es:

En Spring 3.2, los tipos de devolución genéricos para los métodos de fábrica ahora se infieren correctamente, y el cableado automático por tipo para simulacros debería funcionar como se esperaba. Como resultado, es probable que ya no sean necesarias soluciones personalizadas como MockitoFactoryBean, EasyMockFactoryBean o Springockito.

Lo que significa que esto debería funcionar fuera de la caja:

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

El siguiente código funciona con el cableado automático: no es la versión más corta pero es útil cuando debería funcionar solo con frascos de resorte / mockito estándar.

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

Si está usando spring> = 3.0 , intente usar la @Configurationanotación Springs para definir parte del contexto de la aplicación

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

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

}

Si no desea utilizar @ImportResource, también puede hacerlo al revés:

<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 obtener más información, eche un vistazo a spring-framework-reference: configuración de contenedor basada en Java

Quizás no sea la solución perfecta, pero tiendo a no usar el resorte para hacer DI para las pruebas unitarias. las dependencias para un solo bean (la clase bajo prueba) generalmente no son demasiado complejas, así que solo hago la inyección directamente en el código de prueba.

Puedo hacer lo siguiente usando Mockito:

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

Publicar algunos ejemplos basados ​​en los enfoques anteriores

Con la primavera:

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

Sin primavera:

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

Actualización : nueva respuesta aquí: https://stackoverflow.com/a/19454282/411229 . Esta respuesta solo se aplica a las versiones Spring anteriores a la 3.2.

He buscado por un tiempo una solución más definitiva para esto. Esta publicación de blog parece cubrir todas mis necesidades y no se basa en el pedido de declaraciones de frijol. Todo el crédito a Mattias Severson. http://www.jayway.com/2011/11/30/spring-integration-tests-part-i-creating-mock-objects/

Básicamente, implemente 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;
    }
}

A continuación, actualice su configuración de primavera con lo siguiente:

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

Mirando el ritmo de desarrollo de Springockito y la cantidad de problemas abiertos , me preocuparía un poco introducirlo en mi paquete de pruebas hoy en día. El hecho de que el último lanzamiento se realizó antes del lanzamiento de Spring 4 plantea preguntas como "¿Es posible integrarlo fácilmente con Spring 4?". No lo sé porque no lo intenté. Prefiero el enfoque Spring puro si necesito burlarme de Spring Bean en la prueba de integración.

Hay una opción para falsificar Spring Bean con características simples de Spring. Necesita usar @Primary, @Profiley @ActiveProfilesanotaciones para ello. Escribí una publicación de blog sobre el tema.

Encontré una respuesta similar a la de teabot para crear un MockFactory que proporciona los simulacros. Usé el siguiente ejemplo para crear la fábrica simulada (ya que el enlace a narkisr está muerto): 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>

Esto también ayuda a evitar que Spring quiera resolver las inyecciones del frijol burlado.

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

esto ^ funciona perfectamente bien si se declara primero / temprano en el archivo XML. Mockito 1.9.0 / Spring 3.0.5

Utilizo una combinación del enfoque utilizado en la respuesta por Markus T y una implementación auxiliar simple ImportBeanDefinitionRegistrarque busca una anotación personalizada ( @MockedBeans) en la que se puede especificar qué clases se deben burlar. Creo que este enfoque da como resultado una prueba de unidad concisa con parte del código repetitivo relacionado con la burla eliminada.

Así es como se ve una prueba de unidad de muestra con ese enfoque:

@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 que esto suceda, debe definir dos clases auxiliares simples: anotación personalizada ( @MockedBeans) y una ImportBeanDefinitionRegistrarimplementación personalizada . @MockedBeansla definición de anotación debe ser anotada @Import(CustomImportBeanDefinitionRegistrar.class)y la ImportBeanDefinitionRgistrarnecesidad de agregar definiciones de beans simulados a la configuración en su registerBeanDefinitionsmétodo.

Si le gusta el enfoque, puede encontrar implementaciones de muestra en mi blog .

Desarrollé una solución basada en la propuesta de Kresimir Nesek. Agregué una nueva anotación @EnableMockedBean para hacer que el código sea un poco más limpio y 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();
    }

}

He escrito un post explicándolo.

Sugeriría migrar su proyecto a Spring Boot 1.4. Después de eso, puede usar una nueva anotación @MockBeanpara falsificar sucom.package.Dao

Hoy descubrí que un contexto primaveral donde declaraba un antes de los frijoles Mockito, no se cargaba. Después de mover DESPUÉS de los simulacros, el contexto de la aplicación se cargó correctamente. Cuídate :)

Para el registro, todas mis pruebas funcionan correctamente simplemente haciendo que el dispositivo se inicialice lentamente, por ejemplo:

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

Supongo que la razón es la que Mattias explica aquí (al final de la publicación), que una solución alternativa está cambiando el orden en que se declaran los beans: la inicialización diferida es "una especie de" tener el dispositivo declarado al final.

Si usa la inyección del controlador, asegúrese de que sus variables locales NO sean "finales"