¿Cuál es el uso real de 'fail' en el caso de prueba JUnit?

¿Cuál es el uso real de 'fail' en el caso de prueba JUnit?

Algunos casos en los que lo he encontrado útil:

• marca una prueba que está incompleta, por lo que falla y te advierte hasta que puedas terminarla
• asegurándose de que se lanza una excepción:

try{
  // do stuff...
  fail("Exception not thrown");
}catch(Exception e){
  assertTrue(e.hasSomeFlag());
}

Nota:

Desde JUnit4, hay una forma más elegante de probar que se lanza una excepción: use la anotación @Test(expected=IndexOutOfBoundsException.class)

Sin embargo, esto no funcionará si también desea inspeccionar la excepción, entonces aún necesita fail().

digamos que está escribiendo un caso de prueba para un flujo -ve donde el código que se está probando debería generar una excepción

try{
   bizMethod(badData);
   fail(); // FAIL when no exception is thrown
} catch (BizException e) {
   assert(e.errorCode == THE_ERROR_CODE_U_R_LOOKING_FOR)
}

Creo que el caso de uso habitual es llamarlo cuando no se arrojó ninguna excepción en una prueba negativa.

Algo parecido al siguiente pseudocódigo:

test_addNilThrowsNullPointerException()
{
    try {
        foo.add(NIL);                      // we expect a NullPointerException here
        fail("No NullPointerException");   // cause the test to fail if we reach this            
     } catch (NullNullPointerException e) {
        // OK got the expected exception
    }
}

Lo he usado en el caso de que algo haya salido mal en mi método @Before.

public Object obj;

@Before
public void setUp() {
    // Do some set up
    obj = new Object();
}

@Test
public void testObjectManipulation() {
    if(obj == null) {
        fail("obj should not be null");
     }

    // Do some other valuable testing
}

Así es como utilizo el método Fail.

Hay tres estados en los que puede terminar su caso de prueba

1. Aprobado: la función bajo prueba se ejecutó correctamente y devolvió los datos como se esperaba
2. No aprobado: la función bajo prueba se ejecutó con éxito pero los datos devueltos no fueron los esperados
3. Fallido: la función no se ejecutó correctamente y esto no fue

previsto (a diferencia de los casos de prueba negativos que esperan que ocurra una excepción).

Si está utilizando eclipse, los tres estados se indican con un marcador verde, azul y rojo, respectivamente.

Utilizo la operación de error para el tercer escenario.

por ejemplo: public Integer add (integer a, Integer b) {return new Integer (a.intValue () + b.intValue ())}

1. Caso aprobado: a = new Integer (1), b = new Integer (2) y la función devolvió 3
2. Caso no aprobado: a = nuevo número entero (1), b = nuevo número entero (2) y la función devolvió un valor diferente de 3
3. Caso fallido: a = nulo, b = nulo y la función arroja una NullPointerException

Yo, por ejemplo, uso fail() para indicar pruebas que aún no están terminadas (sucede); de lo contrario, se mostrarían exitosos.

Esto quizás se deba al hecho de que no conozco algún tipo de funcionalidad incompleta (), que existe en NUnit.

En configuraciones concurrentes y / o asincrónicas, es posible que desee verificar que ciertos métodos (por ejemplo, delegados, detectores de eventos, manejadores de respuestas, lo que sea) no se llaman. Dejando a un lado los frameworks de burla, puedes llamarfail() a esos métodos para fallar las pruebas. Los tiempos de espera vencidos son otra condición de falla natural en tales escenarios.

Por ejemplo:

final CountDownLatch latch = new CountDownLatch(1);

service.asyncCall(someParameter, new ResponseHandler<SomeType>() {
    @Override
    public void onSuccess(SomeType result) {
        assertNotNull(result);
        // Further test assertions on the result
        latch.countDown();
    }

    @Override
    public void onError(Exception e) {
        fail(exception.getMessage());
        latch.countDown();
    }
});

if ( !latch.await(5, TimeUnit.SECONDS) ) {
    fail("No response after 5s");
}

El caso de uso más importante es probablemente la comprobación de excepciones.

Si bien junit4 incluye el elemento esperado para verificar si ocurrió una excepción, parece que no forma parte del nuevo junit5. Otra ventaja de usar fail()sobre el expectedes que puede combinarlo finallypermitiendo la limpieza de casos de prueba.

dao.insert(obj);
try {
  dao.insert(obj);
  fail("No DuplicateKeyException thrown.");
} catch (DuplicateKeyException e) {
  assertEquals("Error code doesn't match", 123, e.getErrorCode());
} finally {
  //cleanup
  dao.delete(obj);
}

Como se señaló en otro comentario. Tener una prueba para fallar hasta que pueda terminar de implementarla también suena razonable.