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


Respuestas:


138

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().


5
Considere esta publicación de blog sobre los méritos relativos de anotación fallida frente a esperada: blog.jooq.org/2016/01/20/…
lbalazscs

4
@sleske "si también desea inspeccionar la excepción, aún necesita fail ()" - nop. ExpectedException es el camino, consulte github.com/junit-team/junit4/wiki/exception-testing
kraxor

@kraxor: Es cierto, no lo sabía cuando escribí la respuesta (probablemente ni siquiera estaba por ahí).
sleske

14

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)
}

10

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
    }
}

3
Si no marca algo en el bloque catch, puede usar la anotación del método @ExpectedException (NullNullPointerException.class) para declarar que espera una excepción (de un tipo especial).
Viernes

8

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
}

1
Sí, probar las condiciones previas es bueno. Sin embargo, si desea asegurarse de que el @Beforemétodo tuvo éxito, probablemente sea mejor verificarlo directamente en ese método. Como beneficio adicional, al menos JUnit y TestNG incluso informarán una falla diferente para los errores de los métodos @Before/ @After, por lo que pueden ver que el problema no estaba en la prueba en sí.
sleske

4

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

1
Si observa el código fuente de JUnit, verá que las aserciones usan fail().
Daniel C. Sobral

3

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.


2

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");
}

0

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.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.