Solución:
los SpringRunner
proporciona soporte para cargar un resorte ApplicationContext
y comer frijoles @Autowired
en su instancia de prueba. En realidad, hace mucho más que eso (cubierto en el Manual de referencia de Spring), pero esa es la idea básica.
Mientras que el MockitoJUnitRunner
proporciona soporte para crear simulacros y espías con Mockito.
Sin embargo, con JUnit 4, solo puede usar una Runner
a la vez.
Por lo tanto, si desea utilizar el soporte de Spring y Mockito simultáneamente, solo puede elegir uno de esos corredores.
Pero estás de suerte ya que tanto Spring como Mockito brindan normas además de corredores.
Por ejemplo, puede usar el corredor de primavera con la regla Mockito de la siguiente manera.
@RunWith(SpringRunner.class)
@SpringBootTest
public class MyTests {
@Rule
public MockitoRule rule = MockitoJUnit.rule();
@Mock
MyService myService;
// ...
}
Aunque, por lo general, si está usando Spring Boot y necesita simular un frijol de la primavera ApplicationContext
entonces usarías Spring Boot’s @MockBean
apoyo en lugar de simplemente @Mock
.
Cuando SpringRunner.class
se utiliza, Spring proporciona las anotaciones correspondientes:
-
@MockBean
@SpyBean
Los simulacros se inyectan a los objetos sometidos a pruebas a través de @Autowired
anotación. Para habilitar esta funcionalidad, las pruebas deben estar anotadas con
-
@SpringBootTest
o
@TestExecutionListeners(MockitoTestExecutionListener.class)
Se pueden encontrar más detalles y ejemplos en la documentación oficial: Mocking and Spying Beans
Según JavaDoc:
SpringRunner es un alias para
SpringJUnit4ClassRunner
. Para usar esta clase, simplemente anote una clase de prueba basada en JUnit 4 con@RunWith(SpringRunner.class)
. Si desea utilizar SpringTestContext
Marco con un corredor que no sea este, useorg.springframework.test.context.junit4.rules.SpringClassRule
yorg.springframework.test.context.junit4.rules.SpringMethodRule
.
Y el JavaDoc de TestContext
:
TestContext
encapsula el contexto en el que se ejecuta una prueba, independientemente del marco de prueba real en uso.
El del método getApplicationContext()
:
Obtenga el contexto de la aplicación para este contexto de prueba, posiblemente almacenado en caché. Las implementaciones de este método son responsables de cargar el contexto de la aplicación si el contexto correspondiente aún no se ha cargado, lo que potencialmente también almacena en caché el contexto.
Entonces, SpringRunner carga el contexto y es responsable de mantenerlo. Por ejemplo, si desea conservar los datos en una base de datos incorporada, como la base de datos H2 en memoria, debe usar SpringRunner.class
; y, para limpiar las tablas y deshacerse de los registros que insertó después de cada prueba, anote la prueba con @DirtiesContext
para decirle a Spring que lo limpie.
Pero, esto ya es una prueba de integración o componente. Si su prueba es pura prueba unitaria, no tiene que cargar DB, o simplemente desea verificar que se llame a algún método de una dependencia, MockitoJUnit4Runner
es suficiente. Solo usa @Mock
como quieras y Mockito.verify(...)
y la prueba pasará. Y es mucho más rápido.
La prueba debe ser rápida. Tan rápido como sea posible. Entonces, siempre que sea posible, use MockitoJUnit4Runner
para acelerarlo.