Pourquoi ne pas JUnit fournir assertNotEquals méthodes?

Je vous suggère d'utiliser le nouveau assertThat() style s'affirme, qui peut facilement décrire tous les types de négations et de construire automatiquement une description de ce qui vous attend et ce que vous avez obtenu, si l'assertion échoue:

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

Tous les trois options sont équivalentes, choisissez celle que vous trouvez la plus lisible.

D'utiliser les simples noms de méthodes (et permettre à cette tendue syntaxe de travail), vous avez besoin de ces importations:

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

Je me demande même. L'API de l'Assertion n'est pas très symétrique; pour tester si les objets sont les mêmes, il fournit assertSame et assertNotSame.

Bien sûr, il n'est pas trop long à écrire:

assertFalse(foo.equals(bar));

Avec une telle affirmation, la seule partie informative de la sortie est malheureusement le nom de la méthode d'essai, de sorte descriptif message doit être formé séparément:

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

C'est donc fastidieux, que c'est mieux de rouler vos propres assertNotEqual. Heureusement, dans l'avenir, il sera peut-être partie de la JUnit: JUnit numéro 22

Je suis venue à cette partie assez tard, mais j'ai trouvé que la forme:

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

peut être mis en oeuvre pour la plupart des "pas égal à' cas.

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

La raison évidente que les gens voulaient assertNotEquals() était de comparer les builtins sans avoir à les convertir à pleine soufflé d'objets:

Verbose exemple:

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

vs

assertNotEqual(1, winningBidderId);

Malheureusement depuis Eclipse ne comprend pas JUnit 4.11 par défaut, vous devez être commentée.

Mise en garde, je ne pense pas que le " 1 " doit être enveloppé dans un Entier.valueOf (), mais depuis que je suis récemment retourné à partir de .NET ne comptez pas sur mon exactitude.

Je suis totalement d'accord avec l'OP de point de vue. Assert.assertFalse(expected.equals(actual)) n'est pas une façon naturelle d'exprimer une inégalité.

Mais je dirais que, plus loin que Assert.assertEquals(), Assert.assertNotEquals() fonctionne mais n'est pas convivial du document ce que le test s'affirme et de comprendre/debug que l'assertion échoue.

Donc oui, JUnit 4.11 et JUnit 5 fournit Assert.assertNotEquals() (Assertions.assertNotEquals() dans JUnit 5) mais j'ai vraiment éviter de les utiliser.

Comme alternative, pour affirmer l'état d'un objet que j'générales d'utilisation d'un comparateur de API qui creuse dans l'état de l'objet facilement, ce document clairement l'intention de les affirmations et c'est très convivial pour comprendre la cause de l'échec de l'assertion.

Ici est un exemple.

Supposons que j'ai un Animal de la classe qui je veux tester le createWithNewNameAndAge() méthode, une méthode qui crée un nouvel Animal objet en changeant son nom et son âge, mais en gardant sa nourriture préférée.

Supposons que j'utilise Assert.assertNotEquals() d'affirmer que l'original et les nouveaux objets sont différents.

Ici est l'Animal de la classe avec des défauts de mise en œuvre de createWithNewNameAndAge() :

public class Animal {
private String name;
private int age;
private String favoriteFood;
public Animal(String name, int age, String favoriteFood) {
this.name = name;
this.age = age;
this.favoriteFood = favoriteFood;
}
//Flawed implementation : use this.name and this.age to create the 
//new Animal instead of using the name and age parameters
public Animal createWithNewNameAndAge(String name, int age) {
return new Animal(this.name, this.age, this.favoriteFood);
}
public String getName() {
return name;
}
public int getAge() {
return age;
}
public String getFavoriteFood() {
return favoriteFood;
}
@Override
public String toString() {
return "Animal [name=" + name + ", age=" + age + ", favoriteFood=" + favoriteFood + "]";
}
@Override
public int hashCode() {
final int prime = 31;
int result = 1;
result = prime * result + age;
result = prime * result + ((favoriteFood == null) ? 0 : favoriteFood.hashCode());
result = prime * result + ((name == null) ? 0 : name.hashCode());
return result;
}
@Override
public boolean equals(Object obj) {
if (!(obj instanceof Animal)) return false;
Animal other = (Animal) obj;
return age == other.age && favoriteFood.equals(other.favoriteFood) &&
name.equals(other.name);
}
}

JUnit 4.11+ (ou JUnit 5) à la fois en tant que lanceur de test et l'affirmation de l'outil

@Test
void assertListNotEquals_JUnit_way() {
Animal scoubi = new Animal("scoubi", 10, "hay");
Animal littleScoubi = scoubi.createWithNewNameAndAge("little scoubi", 1);
Assert.assertNotEquals(scoubi, littleScoubi);
}

Le test échoue comme prévu, mais la cause fournies par le développeur n'est vraiment pas utile. Il dit seulement que les valeurs doivent être différents et de sortie de la toString() raison invoquée sur le réel Animal paramètre :

java.lang.AssertionError: les Valeurs doivent être différents. Réel: Animal

[nom=scoubi, âge=10, favoriteFood=foin]

au org.junit.Affirmer.fail(Assert.java:88)

Ok les objets ne sont pas égaux. Mais où est le problème ?

Le champ n'est pas correctement évaluée dans la méthode éprouvée ? Un ? Deux ? Chacun d'eux ?

Pour le découvrir, vous avez à creuser dans la createWithNewNameAndAge() de mise en œuvre/l'utilisation d'un débogueur tandis que le test de l'API serait beaucoup plus facile si il serait pour nous la différence entre ce qui est prévu et ce qui est obtenu.

---

JUnit 4.11 comme lanceur de test et un test de Matcher API comme affirmation de l'outil

Ici le même scénario de test, mais qui utilise AssertJ (un excellent test de matcher API) afin de rendre l'affirmation de la Animal état: :

import org.assertj.core.api.Assertions;
@Test
void assertListNotEquals_AssertJ() {
Animal scoubi = new Animal("scoubi", 10, "hay");
Animal littleScoubi = scoubi.createWithNewNameAndAge("little scoubi", 1);
Assertions.assertThat(littleScoubi)
.extracting(Animal::getName, Animal::getAge, Animal::getFavoriteFood)
.containsExactly("little scoubi", 1, "hay");
}

Bien sûr, le test échoue toujours, mais cette fois, la raison est clairement indiqué :

java.lang.AssertionError:

Attend:

<["scoubi", 10, "foin"]>

pour contenir exactement (et dans le même ordre):

<["peu scoubi", 1, "foin"]>

mais certains éléments n'ont pas été trouvés:

<["peu scoubi", 1]>

et d'autres n'ont pas attendu:

<["scoubi", 10]>

à junit5.MyTest.assertListNotEquals_AssertJ(MyTest.java:26)

Nous pouvons lire que pour Animal::getName, Animal::getAge, Animal::getFavoriteFood valeurs de retour des Animaux, nous nous attendons à avoir les valeurs suivantes :

"little scoubi", 1, "hay" 

mais nous avons eu ces valeurs :

"scoubi", 10, "hay"

Donc nous savons où étudier : name et age ne sont pas correctement évalués.
En outre, le fait de spécifier la hay valeur dans l'affirmation de Animal::getFavoriteFood() permet également à plus finement affirmer le retour de l' Animal. Nous voulons que les objets-être pas le même pour certaines propriétés, mais pas nécessairement pour toutes les propriétés.

Donc, définitivement, à l'aide d'un comparateur de API est beaucoup plus clair et plus souple.