web-dev-qa-db-fra.com

Quelle est l'utilisation réelle de 'échec' dans le scénario de test JUnit?

Quelle est l'utilisation réelle de 'échec' dans le scénario de test JUnit?

javaunit-testingjunitjunit4
109
Sanju

Quelques cas où je l’ai trouvé utile:

  • marquer un test qui est incomplet, donc il échoue et vous avertit jusqu'à ce que vous puissiez le terminer
  • en s'assurant qu'une exception est levée:
try{
  // do stuff...
  fail("Exception not thrown");
}catch(Exception e){
  assertTrue(e.hasSomeFlag());
}

Remarque:

Depuis JUnit4, il existe un moyen plus élégant de vérifier qu’une exception est générée: utilisez l’annotation @Test(expected=IndexOutOfBoundsException.class)

Cependant, cela ne fonctionnera pas si vous souhaitez également inspecter l'exception, vous avez toujours besoin de fail().

124
sleske

disons que vous écrivez un scénario de test pour un flux -ve où le code testé doit générer une exception

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

Je pense que le cas d'utilisation habituel est de l'appeler quand aucune exception n'a été lancée dans un test négatif.

Quelque chose comme le pseudo-code suivant:

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

Je l'ai utilisé dans le cas où quelque chose aurait mal tourné dans ma méthode @Avant.

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

Voici comment j'utilise la méthode Fail.

Il y a trois états dans lesquels votre cas de test peut aboutir

  1. Réussi: la fonction testée a été exécutée avec succès et a renvoyé les données comme prévu.
  2. Pas réussi: la fonction testée a été exécutée avec succès, mais les données renvoyées n'étaient pas comme prévu.
  3. Failed: La fonction ne s’est pas exécutée avec succès et ce n’est pas le cas.

prévu (contrairement aux tests élémentaires négatifs dans lesquels une exception devrait se produire).

Si vous utilisez Eclipse, trois états sont indiqués par un marqueur vert, bleu et rouge respectivement.

J'utilise l'opération d'échec pour le troisième scénario.

par exemple. : public Integer add (entier a, Integer b) {renvoie le nouvel entier (a.intValue () + b.intValue ())}

  1. Cas passé: a = nouvel Interger (1), b = nouvel Integer (2) et la fonction renvoyée 3
  2. Cas non passé: a = nouvel Interger (1), b = nouvel Integer (2) et la fonction a renvoyé une valeur soem différente de 3
  3. Cas ayant échoué: a = null, b = null et la fonction lève une exception NullPointerException
3
user3044364

Par exemple, j’utilise fail() pour indiquer des tests qui ne sont pas encore terminés (c’est le cas); sinon, ils montreraient comme un succès.

Ceci est peut-être dû au fait que je ne suis pas au courant d'une sorte de fonctionnalité incomplète (), qui existe dans NUnit.

2
Alen Siljak

Dans les paramètres simultanés et/ou asynchrones, vous pouvez vérifier que certaines méthodes (par exemple, les délégués, les écouteurs d'événements, les gestionnaires de réponses, vous le nommez) ne sont pas appelé. Mis à part les frameworks, vous pouvez appeler fail() dans ces méthodes pour faire échouer les tests. Les délais expirés sont une autre condition d'échec naturel dans de tels scénarios.

Par exemple:

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

Le cas d'utilisation le plus important est probablement la vérification des exceptions.

Bien que junit4 inclue le élément attend pour vérifier si une exception s'est produite, il semble que cela ne fasse pas partie du nouveau junit5. Un autre avantage de l'utilisation de fail() sur expected est que vous pouvez le combiner avec finally, ce qui permet de nettoyer le scénario de test.

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

Comme noté dans un autre commentaire. Avoir un test qui échoue jusqu'à ce que vous ayez fini de le mettre en œuvre semble également raisonnable.

0
Udo Held