Warum bietet JUnit keine assertNotEquals-Methoden?

Question 1

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

Es bietet assertNotSame (korrespondierend zu assertSame) und assertFalse (korrespondierend zu assertTrue), also scheint es seltsam, dass sie sich nicht darum gekümmert haben assertNotEqual.

Übrigens weiß ich, dass JUnit-Addons die Methoden bietet, nach denen ich suche. Ich frage nur aus Neugier.

Question 2

Ich würde vorschlagen, dass Sie die neuere verwenden assertThat() Stil-Asserts, die alle Arten von Negationen leicht beschreiben und automatisch eine Beschreibung dessen erstellen können, was Sie erwartet haben und was Sie erhalten 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 lesbarsten finden.

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

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

Question 3

Da ist ein 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;

Question 4

Ich frage mich genauso. Die API von Assert ist nicht sehr symmetrisch; zum Testen, ob Objekte gleich sind, bietet es assertSame und assertNotSame.

Natürlich ist es nicht zu lang, um zu schreiben:

assertFalse(foo.equals(bar));

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

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. Zum Glück wird es in Zukunft vielleicht Teil der JUnit sein: JUnit-Ausgabe 22

Question 5

Ich würde argumentieren, dass das Fehlen von assertNotEqual tatsächlich eine Asymmetrie ist und JUnit etwas weniger erlernbar macht. Beachten Sie, dass dies ein netter Fall ist, wenn 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 liegen könnte, dass zu wenige Leute die Methode fordern. Ich erinnere mich jedoch an eine Zeit, als es nicht einmal assertFalse gab; daher habe ich eine positive Erwartung, dass die Methode eventuell hinzugefügt wird, da sie nicht schwierig ist; obwohl ich anerkenne, dass es zahlreiche Problemumgehungen gibt, sogar elegante.

Question 6

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

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

kann für die meisten „ungleichen“ Fälle verwendet werden.

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

Question 7

Ich arbeite an JUnit in einer Java 8-Umgebung und verwende jUnit4.12

für mich: Compiler konnte die Methode assertNotEquals nicht finden, selbst wenn ich sie verwendet habe
import org.junit.Assert;

Also habe ich gewechselt
assertNotEquals("addb", string);
zu
Assert.assertNotEquals("addb", string);

Wenn Sie also ein Problem bzgl assertNotEqual nicht erkannt, dann ändern Sie es in Assert.assertNotEquals(,); es sollte dein Problem lösen

Question 8

Der offensichtliche Grund, warum die Leute assertNotEquals() wollten, war, Builtins zu vergleichen, ohne sie zuerst in ausgewachsene Objekte konvertieren zu müssen:

Ausführliches Beispiel:

....
assertThat(1, not(equalTo(Integer.valueOf(winningBidderId))));
....

vs.

assertNotEqual(1, winningBidderId);

Da Eclipse JUnit 4.11 standardmäßig nicht enthält, müssen Sie leider ausführlich sein.

Vorbehalt Ich glaube nicht, dass die ‘1’ in eine Integer.valueOf() eingeschlossen werden muss, aber da ich neu von .NET zurückgekehrt bin, zählen Sie nicht auf meine Korrektheit.