Tengo un objeto que me estoy burlando con un JMockit NonStrictExcpection()
en el método @Before
/setUp()
de mi clase de prueba para que devuelva el valor esperado para la ejecución normal de mi clase bajo prueba.Eliminando expectativas previamente definidas en JMockit
Esto está bien para todos mis métodos de prueba excepto para una sola prueba en la que deseo probar el funcionamiento no normal de este código.
He intentado crear una nueva expectativa en el método de prueba, que creí que anularía las expectativas en el método setUp, pero encontré que la expectativa en el método setUp es la supresión de la nueva expectativa.
Cuando elimino la expectativa de configuración, el método de prueba se comporta como se esperaba (pero todas mis otras pruebas fallan, naturalmente).
¿Cómo debo codificar mi clase de prueba para que pueda tener las expectativas definidas correctamente para cada prueba con la cantidad mínima de código? (Sé que podría copiar/pegar el código de expectativa en cada método de prueba, , pero no quiero hacer eso si se puede evitar).
Mi código de prueba es como la siguiente (nota, esto es psuedocode sorta y no compila, pero se entiende la idea):
public class TestClass{
@Before
public void setUp(){
// Here I define the normal behaviour of mockObject
new NonStrictExpectations() {{
mockObject.doSomething();
result = "Everyting is OK!";
}};
// Other set up stuff...
}
// Other Tests...
/**
* This method tests that an error when calling
* mockObject.doSomething() is handled correctly.
*/
@Test(expected=Exception.class)
public void testMockObjectThrowsException(){
// This Expectation is apparently ignored...
new NonStrictExpectations() {{
mockObject.doSomething();
result = "Something is wrong!";
}};
// Rest of test method...
}
}
No sería esto significa que es necesario invocar manualmente expectTheUnknown() en cada método único? Además, creo que devolver 'NonStrictExpectations' no es realmente necesario. –
@IbrahimArief Ha pasado un tiempo desde que escribí la respuesta, pero AFAIR, el punto de la pregunta OP era que se necesitaba un control más preciso de cuándo se llamaba el método. No creo que haya ninguna duda de que esta solución es un truco, pero al menos funciona :) – Steen
Oh, funciona maravillosamente, no hay dudas al respecto. :) Estaba confirmando mi preocupación de que no parece haber otra forma más que difundir la definición de expectTheUnknown() en cada método en Jmockit en lugar de tener algún tipo de expectativa especial anulando un caso más general. –