Quelle est l’utilisation réelle de ‘fail’ dans le cas de test JUnit?

Quelle est l’utilisation réelle de ‘fail’ dans le cas de test JUnit?

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

  • marquer un test incomplet, 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 tester qu’une exception est en cours de @Test(expected=IndexOutOfBoundsException.class) : Utilisez l’annotation @Test(expected=IndexOutOfBoundsException.class)

Cependant, cela ne fonctionnera pas si vous souhaitez également inspecter l’exception, alors vous devez toujours fail() .

disons que vous écrivez un cas de test pour un stream -ve où le code testé doit déclencher 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) } 

Je pense que le cas d’utilisation habituel est d’appeler cela 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 } } 

Je l’ai utilisé dans le cas où quelque chose a mal tourné dans ma méthode @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 } 

Voici comment j’utilise la méthode Fail.

Votre cas de test peut aboutir à trois états

  1. Passé: La fonction sous test a été exécutée avec succès et a renvoyé les données comme prévu
  2. Non réussi: la fonction sous test a été exécutée avec succès, mais les données renvoyées n’étaient pas conformes aux attentes.
  3. Failed: La fonction n’a pas été exécutée avec succès et ce n’était pas

l’intention (contrairement aux cas de test négatifs qui attendent une exception).

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

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

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

  1. Cas passé: a = new Interger (1), b = nouveau entier (2) et la fonction a renvoyé 3
  2. Cas non réussi: a = new Interger (1), b = new Integer (2) et la fonction a renvoyé une valeur soem autre que 3
  3. Cas échoué: a = null, b = null et la fonction renvoie une exception NullPointerException

utilisez simplement:

 org.junit.Assert.fail("Exception expected"); 

Par exemple, j’utilise fail() pour indiquer les tests qui ne sont pas encore terminés (cela arrive); sinon, ils montreraient comme réussi.

Cela est peut-être dû au fait que je ne connais pas de fonctionnalité incomplète (), qui existe dans NUnit.

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

Alors que junit4 inclut l’ élément attendu pour vérifier si une exception s’est produite, il semble que cela ne fasse pas partie de la nouvelle version de junit5. Un autre avantage de l’utilisation de fail() rapport à expected qui est expected est que vous pouvez le combiner pour finally autoriser le nettoyage des cas 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 pour échouer jusqu’à ce que vous ayez fini de l’implémenter semble également raisonnable.

Dans les parameters simultanés et / ou asynchrones, vous souhaiterez peut-être vérifier que certaines méthodes (delegates, écouteurs d’événements, gestionnaires de réponses, etc.) ne sont pas appelées. Mettant de côté les frameworks, vous pouvez appeler fail() dans ces méthodes pour échouer aux tests. Les expirations expirées 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() { @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"); }