JUnit @Theory : Gibt es eine Möglichkeit, eine aussagekräftige Ausnahme zu werfen?

Question

Ich habe kürzlich den JUnit @Theory-Teststil ausprobiert: Es ist eine wirklich effiziente Möglichkeit zu testen. Allerdings bin ich nicht zufrieden mit den Ausnahmen, die geworfen werden, wenn ein Test fehlschlägt. Beispiel :

import static org.junit.Assert.assertEquals;
import org.junit.experimental.theories.DataPoint;
import org.junit.experimental.theories.Theories;
import org.junit.experimental.theories.Theory;
import org.junit.runner.RunWith;

@RunWith(Theories.class)
public class TheoryAndExceptionTest {

    @DataPoint
    public static String yesDataPoint = "yes";

    @Theory
    public void sayNo(final String say) {
        assertEquals("no",say);
    }
}

Ich erwarte, dass dieser Test eine beschreibende Ausnahme wirft, aber anstatt etwas wie dies zu erhalten:

org.junit.ComparisonFailure: expected:<'[no]'> but was:<'[yes]'>

... erhalte ich dies :

org.junit.experimental.theories.internal.ParameterizedAssertionError: sayNo(yes) at
....
[23 Zeilen nutzloser Stapelverfolgung gekürzt]
...
Caused by: org.junit.ComparisonFailure: expected:<'[no]'> but was:<'[yes]'>
....

Gibt es eine Möglichkeit, die ersten 24 Zeilen loszuwerden, die nichts über *meinen* Test aussagen, außer dass yesDataPoint @DataPoint den Fehler verursacht? Das ist eine Information, die ich benötige, um zu wissen, was nicht funktioniert, aber ich würde wirklich auch gerne wissen, wie es dabei fehlschlägt.

[bearbeitet]

Ich habe die Verwendung von org.fest.assertions durch den klassischen org.junit.Assert.assertEquals ersetzt, um Verwirrung zu vermeiden. Darüber hinaus hat dies auch nichts mit Eclipse zu tun: Diese lange (nutzlose/verwirrende) Stapelverfolgung ist das, was Sie auch erhalten, wenn Sie einen @Theory vom Befehlszeilenfenster ausführen und er fehlschlägt.

Answer 1

Gibt es ein Problem beim Fangen des ComparisonFailure und beim Drucken der GetMessage() davon?

public void sayNo(final String say) {
    try {
        assertThat(say).isEqualTo("no");
    }catch(ComparisonFailure e) {
        System.out.println(e.getMessage);
    }
}

Entschuldigung, wenn ich etwas falsch verstehe.

Bearbeitung: ComparisonFailure hat auch die Methoden getExpected() und getActual(), die Sie aufrufen können, wenn Sie nach bestimmten Formatierungen suchen.

Answer 2

Sie haben eine sehr seltsame Bibliothek. Sie haben eine seltsame Syntax für assertThat. Ich würde vorschlagen:

import org.junit.Test;
import org.junit.runner.RunWith;
import org.junit.experimental.theories.*;
import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;

@RunWith(Theories.class)
public class TheoryAndExceptionTest {

    @DataPoint
    public static String yesDataPoint = "yes";

    @Theory
    public void sayNo(final String say) {

        assertThat(say,is("no"));
    }

    @Test
    public void yesNo() {
        assertEquals("muss gleich sein, ", "yes","no");
    }
}

Dann haben Sie:

org.junit.experimental.theories.internal.ParameterizedAssertionError: sayNo(yesDataPoint)
....

Ursache: java.lang.AssertionError: 
Expected: is "no"
     got: "yes"

Was assertEqual betrifft, haben Sie recht, es scheint nicht für Theories nützlich zu sein. Nur für den @Test:

    org.junit.ComparisonFailure: muss gleich sein,  erwartet:<[yes]> aber war:<[no]>

Eine Ergänzung:

Sie können auch verwenden

assertThat("muss gleich sein, ", say,is("no"));

Dann erhalten Sie die Ausgabe:

Ursache: java.lang.AssertionError: muss gleich sein, 
Expected: is "no"
     got: "yes"

Was das Filtern von zusätzlichen Zeilen betrifft, verwenden Sie die Fehlerverlauf-Ansicht in Eclipse.