Quelle est la différence entre l'échec et l'erreur dans JUnit?

Je suis en cours d'exécution JUnit tests sur une grande base de code, et j'ai réalisé que j'obtiens parfois des "Erreurs", tandis que d'autres fois je reçois des "Échecs". Quelle est la différence?

InformationsquelleAutor froadie | 2010-08-06
  1. 110

    Ok, je viens de remarqué un modèle et pense que j'ai compris (corrigez-moi si je me trompe). Il me semble que les échecs sont quand vos cas de test fail - c'est à dire vos affirmations sont erronées. Les erreurs sont des erreurs qui se produisent lors de la tentative pour exécuter le test - des exceptions, etc.

    • Vous avez raison, monsieur.
    • Mais si quelque chose s'étendant java.lang.AssertionError est levée, il sera affiché comme un échec de test à la place d'un test d'erreur. Vous devriez envisager d'accepter votre propre réponse, car il est correct.
    • Oui, c'est exactement la différence. Et à partir d'une perspective pragmatique, il n'y a "pas de différence" -- dans ce si vous obtenez une erreur ou un échec, alors vous avez besoin de réparer. Donc c'était probablement une erreur de compter les "échecs" et "erreurs" séparément dans JUnit. JUnit 4 combine les deux (comme expliqué dans la réponse ci-dessous).
    • Et si l'exception est prévue, vous devez annoté de la @Test avec expected = SomeException.class.
    • il y a une pragmatique de la différence. Si un comportement est invoqué dans de multiples cas de test, je peux encore écrire un seul cas de test qui affirme que le comportement, en plus de lancer les, susceptibles de l'exécution des exceptions dans tout le reste. C'est dire que le reste des cas de tests sont des tests de quelque chose d'autre, même si elles dépendent encore que certains comportements afin de l'exécuter. Lorsque ce comportement est cassé, un seul cas de test sera une défaillance de l'état, tandis que le reste des rapports d'erreur, et à partir de ce que je peux voir que j'ai exactement un bug à corriger, même si de nombreux cas de test n'a pas réussi.
    • org.junit.Affirmer.assertEquals() si échec est considéré comme ERREUR par JUnit4 de rapport HTML. Cela contredit votre affirmation(que je connaissais jusqu'à maintenant). Pouvez-vous s'il vous plaît mettre plus de lumière sur ce point?

    InformationsquelleAutor froadie
  2. 13

    Si votre test déclenche une exception qui n'obtient pas propagée à travers l'Affirmation cadre de Junit, il est rapporté comme une erreur. Par exemple, un NullPointer, ou un ClassNotFound exception signaler une erreur:

    String s = null;
s.trim();

    ou,

    try {

    //your code
} catch(Exception e) {
    //log the exception
    throw new MyException(e);
}

    Ayant dit que, le suivant sera un échec:

    Assert.fail("Failure here");

    ou,

    Assert.assertEquals(1, 2);

    ou encore:

    throw new AssertionException(e);

    Il dépend de la Junit version que vous utilisez. Junit 4 - permettra de faire la distinction entre un échec et une erreur, mais Junit 4 simplifie comme des échecs.

    Lien suivant fournit plus d'informations intéressantes:

    http://www.devx.com/Java/Article/31983/1763/page/2

    • Ce n'est pas précis. La distinction entre l'échec de test et d'erreur de test n'est pas allé dans JUnit 4. J'ai juste testé. L'article lié est trompeuse. Il a dit "JUnit 4 en fait plus simple qu'en utilisant des échecs" mais il faut souligner que JUnit 4 tours de java.lang.AssertionError en échec de test de sorte que vous n'avez pas à utiliser junit.cadre.AssertionFailedError. L'avantage est que vous pouvez commencer à écrire des test affirmations contenues dans le code de production sans que le projet de liaison à JUnit. Distinction entre l'erreur et l'échec du test est également extrêmement utile, et ce serait un pas en arrière si vous l'avez retiré.
    • RonJRH, êtes-vous capable de voir les erreurs dans votre défaut junit rapport?
    • Oui Neel. Je l'ai juste essayé. Pas exactement le etique de la liaison de l'image ici, mais cela montre le résultat de mon test: imagebucket.net/abpxucddkvn1/Capture.PNG
    InformationsquelleAutor Neel
  3. 5

    De "Pragmatique de Tests Unitaires en Java 8 avec JUnit":

    Assertions (ou affirme) dans JUnit sont statiques appels de méthode que vous déposez dans
    vos tests. Chaque affirmation est une occasion de vérifier que certaines conditions
    vrai. Si une prétendue condition n'est pas satisfaite, le test s'arrête juste
    il y a, et JUnit signale un échec de test.

    (Il est également possible que lorsque JUnit exécute votre test, une exception est levée et
    pas pris. Dans ce cas, JUnit signale une erreur de test.)

    InformationsquelleAutor Matias Elorriaga
  4. 4

    Test ci-dessous explique la différence entre Erreur de Test vs échec du Test de la.

    J'ai commenté la ligne qui lance le test de l'erreur et de l'échec du test.

        @Test
    public void testErrorVsTestFailure() {

        final String sampleString = null;

        assertEquals('j', sampleString.charAt(0) );
        //above line throws test error as you are trying to access charAt() method on null reference

        assertEquals(sampleString, "jacob");
        //above line throws Test failure as the actual value-a null , is not equal to expected value-string "jacob"
        }

    Donc Junit test montre d'erreur à chaque fois que vous obtenez une exception , et l'échec du test lorsque le résultat escompté de la valeur ne correspond pas à votre valeur

    InformationsquelleAutor Deen John
  5. 2

    Source de la classe : JUnitReportReporter.java

    public void generateReport(List<XmlSuite> xmlSuites, List<ISuite> suites, String defaultOutputDirectory) {
//......

            for (ITestResult tr : (Set) entry.getValue()) {
                TestTag testTag = new TestTag();

                boolean isSuccess = tr.getStatus() == 1;
                if (!(isSuccess)) {
                    if (tr.getThrowable() instanceof AssertionError)
                        ++errors;
                    else {
                        ++failures;
                    }
                }
}

    Comme vous pouvez le voir en dessous de la ligne dans la méthode ci-dessus

    tr.getThrowable() instanceof AssertionError

    le nombre d'erreurs est accrue lorsqu'il est en instance de AssertionError autrement(tout Throwable) est compté comme des échecs.

    InformationsquelleAutor Roushan
  6. 0

    Vous avez raison que les échecs proviennent de la AssertionErrors jeté par la JUnit méthodes d'assertion, ou en jetant un AssertionError, ou par la levée d'une exception que vous avez déclaré dans votre annotation @Test, et les Erreurs viennent d'autres, exception inattendue. Mais il y a une importante distinction entre eux:

    Un échec signifie que votre test a correctement, et a identifié un défaut dans votre code.

    Une erreur pourrait signifier un bug dans votre code, mais que vous n'avez pas encore de test pour. Cela pourrait également signifier que le bug est dans le test lui-même.

    En bref, un échec signifie que vous avez besoin de réécrire le code qui est en train d'être testé. Une erreur signifie qu'il peut être l'unité de test que vous avez besoin de réécrire. Il peut signifier, même si l'échec était dans votre code, comme un NullPointerException, parce que vous avez détecté un défaut que vous n'avez pas encore de test pour, il pourrait être sage de test pour que.

    InformationsquelleAutor MiguelMunoz