Iniettare Mockito beffe di un fagiolo di primavera

Vorrei iniettare un oggetto simulato Mockito in un bean Spring (3+) ai fini del test unitario con JUnit. Le dipendenze dei miei bean sono attualmente iniettate utilizzando l' @Autowiredannotazione sui campi dei membri privati.

Ho preso in considerazione l'utilizzo ReflectionTestUtils.setFieldma l'istanza bean che desidero iniettare è in realtà un proxy e quindi non dichiara i campi dei membri privati ​​della classe target. Non desidero creare un setter pubblico per la dipendenza in quanto modificherò la mia interfaccia esclusivamente a scopo di test.

Ho seguito alcuni consigli forniti dalla community di Spring, ma la simulazione non viene creata e il cablaggio automatico non riesce:

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

L'errore che attualmente riscontro è il seguente:

...
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 imposto il constructor-argvalore su qualcosa di non valido, non si verifica alcun errore all'avvio del contesto dell'applicazione.

Il modo migliore è:

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

Aggiornamento
Nel file di contesto questo mock deve essere elencato prima di dichiarare qualsiasi campo autowired a seconda di esso.

@InjectMocks
private MyTestObject testObject;

@Mock
private MyDependentObject mockedObject;

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

Ciò inietterà qualsiasi oggetto deriso nella classe di test. In questo caso, inietterà mockedObject in testObject. Questo è stato menzionato sopra ma ecco il codice.

Ho una soluzione molto semplice usando Spring Java Config e 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;
    }
}

Dato:

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

    // etc
}

È possibile caricare la classe testata tramite autowiring, simulare la dipendenza con Mockito e quindi utilizzare Spring's ReflectionTestUtils per iniettare la simulazione nella classe da testare.

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

Prima della primavera 4.3.1, questo metodo non funzionerà con i servizi dietro un proxy (annotato con @Transactional, o Cacheable, per esempio). Questo problema è stato risolto da SPR-14050 .

Per le versioni precedenti, una soluzione è quella di scartare il proxy, come descritto qui: l' annotazione transazionale evita che i servizi vengano derisi (che è ciò che ReflectionTestUtils.setFieldfa di default ora)

Se stai usando Spring Boot 1.4, ha un modo fantastico di farlo. Usa semplicemente un nuovo marchio @SpringBootTestnella tua classe e @MockBeansul campo e Spring Boot creerà una simulazione di questo tipo e lo inserirà nel contesto (invece di iniettare quello originale):

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

}

D'altra parte, se non stai usando Spring Boot o stai usando una versione precedente, dovrai fare un po 'più di lavoro:

Crea un @Configurationbean che inietta le tue beffe nel contesto Spring:

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

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

Usando l' @Primaryannotazione stai dicendo a primavera che questo bean ha la priorità se non viene specificato alcun qualificatore.

Assicurati di annotare la classe con @Profile("useMocks")per controllare quali classi useranno il mock e quali useranno il bean reale.

Infine, nel tuo test, attiva il userMocksprofilo:

@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 non vuoi usare il mock ma il bean reale, non attivare il useMocksprofilo:

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

Dal 1.8.3 Mockito ha @InjectMocks- questo è incredibilmente utile. I miei test JUnit sono @RunWithl' MockitoJUnitRunnere mi costruire @Mockoggetti che soddisfano tutte le dipendenze per la classe in fase di test, che sono tutti iniettati quando il membro privato è annotato con @InjectMocks.

Ho @RunWithil SpringJUnit4Runnerper il test di integrazione solo ora.

Noterò che non sembra poter iniettare List<T>allo stesso modo di Spring. Cerca solo un oggetto Mock che soddisfi Liste non inietterà un elenco di oggetti Mock. La soluzione alternativa per me era quella di utilizzare un @Spycontro un elenco istanziato manualmente e aggiungere manualmente gli oggetti finti a tale elenco per il test dell'unità. Forse era intenzionale, perché certamente mi costringeva a prestare molta attenzione a ciò che veniva deriso insieme.

Aggiornamento: ora ci sono soluzioni migliori e più pulite a questo problema. Si prega di considerare prima le altre risposte.

Alla fine ho trovato una risposta a ronen sul suo blog. Il problema che stavo avendo è dovuto al metodo che Mockito.mock(Class c)dichiara un tipo di ritorno di Object. Di conseguenza, Spring non è in grado di dedurre il tipo di bean dal tipo restituito dal metodo di fabbrica.

La soluzione di Ronen è quella di creare FactoryBeanun'implementazione che restituisca beffe. L' FactoryBeaninterfaccia consente a Spring di eseguire query sul tipo di oggetti creati dal bean factory.

La definizione del mio bean deriso ora appare come:

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

A partire dalla primavera 3.2, questo non è più un problema. Spring ora supporta Autowiring dei risultati dei metodi di fabbrica generici. Vedi la sezione intitolata "Metodi di fabbrica generici" in questo post del blog: http://spring.io/blog/2012/11/07/spring-framework-3-2-rc1-new-testing-features/ .

Il punto chiave è:

Nella primavera 3.2, i tipi di restituzione generici per i metodi di fabbrica vengono ora correttamente dedotti e l'autowiring per tipo per i mock dovrebbe funzionare come previsto. Di conseguenza, è probabile che non siano più necessarie soluzioni personalizzate come MockitoFactoryBean, EasyMockFactoryBean o Springockito.

Ciò significa che questo dovrebbe funzionare immediatamente:

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

Il codice seguente funziona con il collegamento automatico: non è la versione più breve ma utile quando dovrebbe funzionare solo con vasetti standard a molla / mockito.

<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 stai usando spring> = 3.0 , prova a usare l' @Configurationannotazione Springs per definire parte del contesto dell'applicazione

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

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

}

Se non vuoi usare @ImportResource, puoi farlo anche al contrario:

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

Per ulteriori informazioni, dai un'occhiata a spring-framework-reference: configurazione del contenitore basata su Java

Forse non è la soluzione perfetta, ma tendo a non usare la molla per fare DI per test unitari. le dipendenze per un singolo bean (la classe sotto test) di solito non sono eccessivamente complesse, quindi faccio semplicemente l'iniezione direttamente nel codice del test.

Posso fare quanto segue usando Mockito:

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

Pubblicazione di alcuni esempi basati sugli approcci di cui sopra

Con la primavera:

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

Senza primavera:

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

Aggiornamento : nuova risposta qui: https://stackoverflow.com/a/19454282/411229 . Questa risposta si applica solo a quelli sulle versioni Spring precedenti alla 3.2.

Ho cercato per un po 'una soluzione più definitiva a questo. Questo post sul blog sembra coprire tutte le mie esigenze e non si basa sull'ordinamento delle dichiarazioni dei bean. Tutto il merito a Mattias Severson. http://www.jayway.com/2011/11/30/spring-integration-tests-part-i-creating-mock-objects/

Fondamentalmente, implementa un 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;
    }
}

Quindi aggiorna la configurazione di primavera con il seguente:

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

Guardando il ritmo di sviluppo di Springockito e il numero di problemi aperti , sarei un po 'preoccupato di introdurlo nel mio stack della suite di test al giorno d'oggi. Infatti l'ultima versione è stata fatta prima della versione di Spring 4 solleva domande come "È possibile integrarla facilmente con Spring 4?". Non lo so, perché non l'ho provato. Preferisco il puro approccio Spring se ho bisogno di deridere il bean Spring nel test di integrazione.

C'è un'opzione per falsificare il bean Spring con solo semplici funzionalità Spring. È necessario utilizzare @Primary, @Profilee @ActiveProfilesle annotazioni per esso. Ho scritto un post sul blog sull'argomento.

Ho trovato una risposta simile a teabot per creare una MockFactory che fornisce le beffe. Ho usato il seguente esempio per creare la finta fabbrica (dato che i collegamenti a narkisr sono morti): 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>

Questo aiuta anche a prevenire che Spring voglia risolvere le iniezioni dal fagiolo deriso.

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

questo ^ funziona perfettamente se dichiarato prima / all'inizio del file XML. Mockito 1.9.0 / Primavera 3.0.5

Uso una combinazione dell'approccio usato in risposta da Markus T e una semplice implementazione di supporto ImportBeanDefinitionRegistrarche cerca un'annotazione personalizzata ( @MockedBeans) in cui è possibile specificare quali classi devono essere derise. Credo che questo approccio si traduca in un test unitario conciso con una parte del codice del bollettino relativo alla derisione rimosso.

Ecco come appare un test unitario di esempio con questo approccio:

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

A tal fine, è necessario definire due semplici classi di supporto: l'annotazione personalizzata ( @MockedBeans) e ImportBeanDefinitionRegistrarun'implementazione personalizzata . @MockedBeansla definizione di annotazione deve essere annotata @Import(CustomImportBeanDefinitionRegistrar.class)e la ImportBeanDefinitionRgistrarnecessità di aggiungere definizioni di bean simulati alla configurazione nel suo registerBeanDefinitionsmetodo.

Se ti piace l'approccio puoi trovare implementazioni di esempio sul mio post sul blog .

Ho sviluppato una soluzione basata sulla proposta di Kresimir Nesek. Ho aggiunto una nuova annotazione @EnableMockedBean per rendere il codice un po 'più pulito e modulare.

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

}

Ho scritto un post spiegarlo.

Suggerirei di migrare il tuo progetto su Spring Boot 1.4. Dopodiché puoi usare una nuova annotazione @MockBeanper simulare il tuocom.package.Dao

Oggi ho scoperto che un contesto primaverile in cui avevo dichiarato un prima dei fagioli Mockito, non riusciva a caricarsi. Dopo aver spostato AFTER the mock, il contesto dell'app è stato caricato correttamente. Stai attento :)

Per la cronaca, tutti i miei test funzionano correttamente rendendo il dispositivo inizializzato in modo pigro, ad esempio:

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

Suppongo che la logica sia quella che Mattias spiega qui (in fondo al post), che una soluzione alternativa sta cambiando l'ordine in cui vengono dichiarati i bean - l'inizializzazione lenta è "una specie di" con il dispositivo dichiarato alla fine.

Se si utilizza Controller Injection, assicurarsi che le variabili locali NON siano "definitive"