Escribo una prueba de unidad y quiero usar JUnitParamsRunner
y MockitoJUnitRunner
para una clase de prueba.
Desafortunadamente, lo siguiente no funciona:
@RunWith(MockitoJUnitRunner.class)
@RunWith(JUnitParamsRunner.class)
public class DatabaseModelTest {
// some tests
}
¿Hay alguna forma de usar Mockito y JUnitParams en una clase de prueba?
java
unit-testing
junit
Hans-Helge
fuente
fuente
Respuestas:
No puede hacer esto porque, de acuerdo con las especificaciones, no puede poner la misma anotación dos veces en el mismo elemento anotado.
¿Entonces, cuál es la solución? La solución es poner solo uno
@RunWith()
con un corredor sin el que no pueda permanecer y reemplazar el otro con otra cosa. En su caso, supongo que eliminaráMockitoJUnitRunner
y hará programáticamente lo que hace.De hecho, lo único que hace es ejecutar:
al comienzo del caso de prueba. Entonces, la solución más simple es poner este código en el
setUp()
método:No estoy seguro, pero probablemente debería evitar llamadas múltiples de este método usando flag:
Sin embargo, se puede implementar una solución reutilizable mejor con las reglas de JUnt.
Ahora solo agregue la siguiente línea a su clase de prueba:
y puede ejecutar este caso de prueba con cualquier corredor que desee.
fuente
mockInitialized
es incorrecto. Quieres tener una nueva burla para cada prueba.A partir de JUnit 4.7 y Mockito 1.10.17, esta funcionalidad está incorporada; hay una
org.mockito.junit.MockitoRule
clase. Simplemente puede importarlo y agregar la líneaa tu clase de prueba.
fuente
@Rule public MockitoJUnitRule mockito = new MockitoJUnitRule(this);
MockitoAnnotations.initMocks(this)
es muy lento para crear simulaciones. La forma más eficiente es usar @Runwith (MockitoJunitRunner.class)Esta solución funciona para todos los corredores posibles, no solo para este ejemplo de mockito. Por ejemplo; para Spring, simplemente cambie las clases de corredor y agregue las anotaciones necesarias.
DatabaseModelTest
será ejecutado por JUnit.TestMockitoJUnitRunner
depende de él (por lógica) y se ejecutará dentro del main en un@Test
método, durante la llamadaJUnitCore.runClasses(TestMockitoJUnitRunner.class)
. Este método garantiza que el corredor principal se inicie correctamente antesstatic class TestMockitoJUnitRunner
de que se ejecute el sub corredor, implementando de manera efectiva múltiples@RunWith
anotaciones anidadas con clases de prueba dependientes.También en https://bekce.github.io/junit-multiple-runwith-dependent-tests
fuente
JUnitCore.runClasses()
sin inspeccionar el resultado, corre el riesgo de enmascarar los errores de la prueba interna.assert(JUnitCore.runClasses(TestMockitoJUnitRunner.class).wasSuccessful());
al menos le informará el errorDesde el lanzamiento de PowerMock 1.6, puede hacerlo tan fácilmente como
Explicado aquí https://blog.jayway.com/2014/11/29/using-another-junit-runner-with-powermock/
fuente
En mi caso, estaba tratando de simular algún método en spring bean y
no funciona. En su lugar, debe definir ese bean para que se construya utilizando un método simulado dentro de su archivo xml como sigue.
y agregue ese bean con autowired dentro de su clase de prueba como sigue.
fuente
Echa un vistazo a este enlace https://bekce.github.io/junit-multiple-runwith-dependent-tests/ usando este enfoque combiné un @RunWith (Parameterized.class) - corredor externo - con @RunWith (MockitoJUnitRunner.class) - corredor interior. El único ajuste que tuve que agregar fue hacer que mis variables miembro en la clase externa / corredor estén estáticas para que sean accesibles para el corredor / clase interno / anidado. buena suerte y disfruta.
fuente
Quería ejecutar SWTBotJunit4ClassRunner y org.junit.runners.Parameterized al mismo tiempo, tengo pruebas paramétricas y quiero capturas de pantalla cuando falla la prueba SWT (la función de captura de pantalla la proporciona SWTBotJunit4ClassRunner ). La respuesta de @bekce es excelente y primero quería ir por ese camino, pero fue peculiar pasar por los argumentos. O hacer lo parametrizado en la subclase y perder la información de qué pruebas exactas pasaron / fallaron y solo tienen la última captura de pantalla (ya que los nombres de las capturas de pantalla obtienen el nombre de la prueba en sí). De cualquier manera, fue un poco complicado.
En mi caso, SWTBotJunit4ClassRunner es bastante simple, así que cloné el código fuente de la clase, le di mi propio nombre ParametrizedScreenshotRunner y donde el original estaba extendiendo el TestRunner , mi clase está extendiendo la clase parametrizada , así que en esencia puedo usar mi propio corredor en lugar de los dos anteriores. Resumido, mi propio corredor se extiende sobre el corredor parametrizado mientras implementa la función de captura de pantalla, ahora mi prueba usa este corredor "híbrido" y todas las pruebas funcionan como se esperaba de inmediato (no es necesario cambiar nada dentro de las pruebas).
Así es como se ve (en aras de la brevedad, eliminé todos los comentarios de la lista):
fuente
También puedes probar esto:
fuente