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

Question

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

Answer 1

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

• marquer un test incomplet, il échoue et vous avertit jusqu'à ce que vous pouvez le terminer
• en vous assurant une exception est levée:

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

Note:

Depuis junit4, il y a une plus élégante façon de tester qu'une exception est levée: Utilisez l'annotation @Test(expected=IndexOutOfBoundsException.class)

Cependant, cela ne fonctionnera pas si vous aussi voulez inspecter l'exception, alors vous avez toujours besoin de fail().

Answer 2

Je pense que le cas d'utilisation habituel est de l'appeler lorsqu'aucune exception n'a été généré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 
    } 
} 

Answer 3

permet de dire que vous écrivez un test pour un flux -ve où le code testé devrait soulever 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) 
} 

Answer 4

Voici comment j'utilise la méthode Fail.

Il y a trois états que votre cas de test peut se retrouver dans

1. Passé: La fonction en cours de test exécuté avec succès et renvoyé données comme prévu
2. pas été validé: La fonction en cours de test exécuté avec succès, mais la données renvoyées n'a pas été comme prévu
3. Failed: La fonction n'a pas été exécuté avec succès et ce ne fut pas

destiné (contrairement aux cas de test négatifs qui prévoient une exception à se produisent).

Si vous utilisez eclipse, trois états sont indiqués par un marqueur vert, bleu et rouge respectivement. J'utilise l'opération fail pour le troisième scénario.

par exemple. : public Integer add (entier a, entier b) {return new Entier (a.intValue() + b.intValue())}

1. Passed cas: a = new interger (1), b = new Integer (2) et la fonction retourne 3
2. pas passé de cas: a = new interger (1), b = new Integer (2) et la fonction retourne la valeur soem autre que 3
3. cas a échoué: a = null, b = null et la fonction lance une NullPointerException

Answer 5

Je l'ai utilisé dans le cas où quelque chose peut avoir 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 
} 

Answer 6

I, par exemple, utilise fail() pour indiquer des tests qui ne sont pas encore terminé (il arrive); autrement, ils montreraient comme réussi.

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

Answer 7

utiliser simplement:

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

Answer 8

L'utilisation la plus importante est probablement le cas de vérification d'exception.

Alors que junit4 inclut le expected element pour vérifier si une exception s'est produite, il semble qu'elle ne fasse pas partie de la version plus récente de junit5. Un autre avantage de l'utilisation fail() sur le expected est que vous pouvez le combiner avec finally permettant le nettoyage de 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 d'échec jusqu'à ce que vous puissiez terminer l'implémentation semble raisonnable aussi.