JMock assertIsSatisfied in TearDown?

Question

no sé por qué, pero siempre me han escrito mis pruebas JMock así:

@Test 
public void testMyThing() throws Exception { 
    mockery.checking(new Expectations() {{ 
     oneOf(mockObj).foo(); 
    }}); 
    testObj.bar(); // calls mockObj.foo() 
    mockery.assertIsSatisfied(); 
} 

Pero cuando hay muchas pruebas, es mejor mover assertIsSatisfied al desmontaje?

@After 
public void tearDown() throws Exception { 
    mockery.assertIsSatisfied(); 
} 

Answer 1

La forma recomendada de hacerlo es utilizar el corredor JMock. Anotar la clase con

@RunWith(JMock.class) 
public class TestClass { 

Esto llamará a la aserción en el lugar correcto en el ciclo de vida de la prueba. Desmontaje no es el lugar correcto, ya que una falla podría no informarse correctamente y podría estropear otra limpieza.

También tenemos una regla de burla en el repositorio que funciona con la nueva infraestructura @Rule.

Answer 2

Sí, tiendo a hacerlo en el desmontaje. Mantiene el enfoque de los métodos de prueba individuales en lo que realmente están probando, eliminando el texto estándar en el @After; para mí es crítico que las pruebas sean lo más expresivas y legibles posible.

De hecho, a veces ir más lejos que eso, y utilizar una clase JMockSupport base que se encarga de la Mockery para mí (además de proporcionar implementaciones de conveniencia de mock(...)). Esto es solo una conveniencia, por supuesto, y de ninguna manera un requisito como lo fue en JUnit 3.