Inyectar simulacros de Mockito en un frijol Spring


284

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.


44
Eche un vistazo a esta pequeña criatura: bitbucket.org/kubek2k/springockito/wiki/Home
kubek2k

Este es un enfoque muy limpio, ¡me gusta!
teabot

2
Me tuviste en Springockito-anotaciones.
yihtserns


2
Para aquellos que usan spring 4. *, a partir de enero de 2015, esto no parece estar funcionando con la última versión de mockito de spring y el proyecto parece estar inactivo.
Murali

Respuestas:


130

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.


Recibo un error: "Error al crear un bean con el nombre 'mockito': la definición del bean es abstracta"
tttppp

44
@amra: spring no infiere el tipo de objeto devuelto en este caso ... stackoverflow.com/q/6976421/306488
lisak

77
No sé por qué esta respuesta se vota tanto, el bean resultante no se puede conectar automáticamente porque tiene el tipo incorrecto.
azerole

44
Puede conectarse automáticamente si aparece en primer lugar en el archivo de contexto (antes de que se declaren los campos con conexión automática que dependerían de él)
Ryan Walls del

3
A partir de la primavera 3.2, el orden de los frijoles ya no importa. Consulte la sección titulada "Métodos genéricos de fábrica" ​​en esta publicación de blog: spring.io/blog/2012/11/07/…
Ryan Walls

110
@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.


1
¿Cómo termino un método particular de mockedObject?
Jim Holden

@Teinacher when (mockedObject.execute) .thenReturn (objToReturn); Puede poner eso en el método anterior o dentro de su método de prueba.
chaostheory

40
FYI: Este enfoque no funcionará, si quiero un Autowiring parcial y una burla parcial en MyTestObject
raksja

9
No sé por qué esto no se vota más alto. Si veo más respuestas que contengan XML, las arrojaré.
MarkOfHall

3
¿Por qué no usas Mockito.spy(...)esto en su mockedObjectlugar? Y luego usa when(mockedObject.execute).thenReturn(objToReturn)o doReturn(objToReturn).when(mockedObject).execute(). El segundo no invoca el método real. También puede consultar la Mockito.doCallRealMethod()documentación
Tomasz Przybylski

63

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

44
Por alguna razón con este enfoque, spring intenta crear el bean real de todos modos (en lugar de simulacro) y se ahoga con eso ... ¿Qué estoy haciendo mal?
Daniel Gruszczyk

1
Tengo el mismo problema
Korobko Alex

3
No es primavera, sino que mockito intenta crear una instancia de un bean real si te estás burlando de una clase. Si tiene frijoles que deben burlarse en las pruebas, deben ser implementaciones de una interfaz e inyectarse a través de esa interfaz. Si luego se burla de la interfaz (en lugar de la clase), mockito no intentará crear una instancia de esa clase.
Daniel Gruszczyk

77
¿Cual es el punto? ¿Por qué agregar los campos anotados y el constructor con initMocks? ¿Por qué no solo return Mockito.mock(BeanA.class)adentro getBeanA? De esta manera es más simple y hay menos código. ¿Qué me estoy perdiendo?
Oleg

1
@Oleg parece que tienes tu propia solución, que probablemente deberías publicar como respuesta, para que la comunidad pueda votar sobre ella.
Dawood ibn Kareem

48

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)


Doble @RunWith (SpringJUnit4ClassRunner.class) y utilizo diferentes anotaciones para la clase de prueba (mismo corredor) pero este enfoque funciona para mí, gracias.
user1317422

1
Me inspiró mucho "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". Me encontré con este problema exactamente y no obtuve ninguna pista hasta que vi estas palabras. ¡MUCHAS GRACIAS!
snowfox

1
Esta solución se maneja cuando ha conectado todo el contexto de una aplicación y, para fines de prueba, quiere inyectar un simulacro en un bean aleatorio en su contexto. Utilicé esta respuesta para burlarme de un bean cliente fingido para evitar llamadas REST a otros módulos en una prueba de Módulo. Solo obtuve la anotación InjectMock para trabajar cuando está inyectando simulacros en un bean que está a punto de probar, no en un bean creado por Spring Application Configuration.
Andreas Lundgren

1
Casi un día entero tratando de lograr que @MockBean funcione sin restablecer el contexto y luego me encuentro con esta joya. Exactamente lo que necesitaba, aclamaciones.
Matt R

Funciona, aunque tenga en cuenta que el campo reemplazado podría no restablecerse debido al almacenamiento en caché y algunas pruebas no relacionadas podrían romperse. Por ejemplo, en mi prueba, reemplacé el codificador de contraseña con uno falso y algunas otras pruebas se rompieron debido a fallas de autorización.
alextsil

36

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

55
Esta respuesta debería ir al principio: el soporte de @MockBean en el arranque de primavera también se puede usar sin el arranque de primavera. ¡Puede usarlo en pruebas unitarias solo para que funcione en todas las aplicaciones de primavera!
bedrin

2
@Profile anotación se puede establecer también en la definición del método de frijol, para evitar la creación de clases de configuración independiente
Marcin

¡Gran respuesta! Hice algunos cambios para que funcione con mi web.xmlconfiguración de la vieja escuela y AnnotationConfigWebApplicationContext. Tuve que usar en @WebAppConfigurationlugar de @WebIntegrationTesty @ContextHierarchycon en @ContextConfigurationlugar de @SpringApplicationConfiguration.
UTF_or_Death

Tuve que agregar la @Primaryanotación para mi caso, ya que hubo una llamada fallida dentro de una @PostConstructque quería burlarme, pero el @PostConstructbean 's se creó antes de mi simulación para que no lo usara (hasta que agregué @Primary).
hola

19

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.


Sí, esta es la mejor manera. Springockito en realidad no inyecta las burlas por cualquier razón en mi caso.
chaostheory

13

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>

1
Enlace actualizado a la solución de Ronen: narkisr.com/blog/2008/2647754885089732945
Jeff Martin el

No entiendo eso, el método de fábrica tiene el tipo de retorno Objeto ... Pero la solución de amra tiene un tipo de retorno genérico para que Spring lo reconozca ... Pero la solución de amra no funciona para mí
lisak

Tampoco esta solución, la primavera no inferir el tipo de grano que se devuelve desde el factoryBean por lo tanto, no coincidencia de la haba de tipo [com.package.Dao] ...
Lisak


Este enlace todavía funciona: javadevelopmentforthemasses.blogspot.com/2008/07/... Simplemente deshabilite la redirección de enlaces en su navegador y lo verá, en lugar de verse obligado a mirar el 404 en su nuevo blog.
aproximadamente el

12

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>

9

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> 

Trabajó para mi. Tuve que desenvolver el proxy en mi prueba para verificarlo como se describe aquí: forum.spring.io/forum/spring-projects/aop/…
Holgzn

9

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


Buena esa. Usé esto cuando la prueba que estoy probando es @Autowired en el caso de prueba real.
enkor

8

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.


3
Entiendo tu enfoque. Sin embargo, me encuentro en esta situación en una gran base de código heredado que aún no permite esto fácilmente.
teabot

1
He encontrado que el combo Mockito / Spring es muy útil cuando necesito probar código que depende en gran medida de los aspectos de Spring / AOP (por ejemplo, al probar las reglas de seguridad de Spring). Aunque uno está perfectamente justificado al afirmar que tales pruebas deberían ser una prueba de integración.
Lars Tackmann

@Lars - estuvo de acuerdo - lo mismo podría decirse de las pruebas con las que estoy lidiando.
teabot

7

Puedo hacer lo siguiente usando Mockito:

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

1
Gracias por la respuesta @Alexander. ¿Puedo preguntar: se conecta correctamente? Si es así, ¿qué versiones de Spring / Mockito estás usando?
teabot

6

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

2

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>

2

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.


1

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.


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


1

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 .


1

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.


1

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


0

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


1
Hay algo que falta. 8-) ¿Te mudaste después de las burlas?
Hans-Peter Störr

0

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.


-1

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.