Warum bietet JUnit keine assertNotEquals-Methoden?

Question

Weiß jemand, warum JUnit 4 bietet assertEquals(foo,bar) aber nicht assertNotEqual(foo,bar) Methoden?

Sie bietet assertNotSame (entspricht assertSame ) und assertFalse (entspricht assertTrue ), so dass es seltsam erscheint, dass sie sich nicht die Mühe gemacht haben, auch assertNotEqual .

Übrigens, ich weiß, dass JUnit-addons die Methoden, die ich suche, bereitstellt. Ich frage nur aus Neugierde.

Answer 1

Ich würde vorschlagen, dass Sie die neuere assertThat() Stil-Asserts, die leicht alle Arten von Negationen beschreiben können und automatisch eine Beschreibung dessen erstellen, was Sie erwartet haben und was Sie bekommen haben, wenn die Assertion fehlschlägt:

assertThat(objectUnderTest, is(not(someOtherObject)));
assertThat(objectUnderTest, not(someOtherObject));
assertThat(objectUnderTest, not(equalTo(someOtherObject)));

Alle drei Optionen sind gleichwertig, wählen Sie diejenige, die Sie am besten lesen können.

Um die einfachen Namen der Methoden zu verwenden (und damit diese angespannte Syntax zu funktionieren), benötigen Sie diese Importe:

import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;

Answer 2

Es gibt eine assertNotEquals in JUnit 4.11: https://github.com/junit-team/junit/blob/master/doc/ReleaseNotes4.11.md#improvements-to-assert-and-assume

import static org.junit.Assert.assertNotEquals;

Answer 3

Das frage ich mich auch. Die API von Assert ist nicht sehr symmetrisch; um zu testen, ob die Objekte gleich sind, bietet sie assertSame y assertNotSame .

Natürlich ist es nicht zu lang zum Schreiben:

assertFalse(foo.equals(bar));

Bei einer solchen Behauptung ist der einzige informative Teil der Ausgabe leider der Name der Testmethode, so dass die beschreibende Meldung separat gebildet werden sollte:

String msg = "Expected <" + foo + "> to be unequal to <" + bar +">";
assertFalse(msg, foo.equals(bar));

Das ist natürlich so mühsam, dass es besser ist, selbst zu rollen assertNotEqual . Glücklicherweise wird es in Zukunft vielleicht Teil von JUnit sein: JUnit Ausgabe 22

Answer 4

Ich würde argumentieren, dass das Fehlen von assertNotEqual in der Tat eine Asymmetrie ist und JUnit ein bisschen weniger erlernbar macht. Allerdings ist dies ein klarer Fall, in dem das Hinzufügen einer Methode die Komplexität der API verringern würde, zumindest für mich: Symmetrie hilft, den größeren Raum zu beherrschen. Meine Vermutung ist, dass der Grund für die Auslassung darin liegt, dass zu wenige Leute die Methode aufrufen. Ich erinnere mich jedoch an eine Zeit, in der es nicht einmal assertFalse gab; daher habe ich eine positive Erwartung, dass die Methode irgendwann hinzugefügt wird, da sie nicht schwierig ist; auch wenn ich einräume, dass es zahlreiche, sogar elegante Umgehungsmöglichkeiten gibt.

Answer 5

Ich komme ziemlich spät zu dieser Party, aber ich habe festgestellt, dass die Form:

static void assertTrue(java.lang.String message, boolean condition) 

kann für die meisten "Nicht-Gleichheitsfälle" verwendet werden.

int status = doSomething() ; // expected to return 123
assertTrue("doSomething() returned unexpected status", status != 123 ) ;