Pourquoi JUnit ne fournit-il pas de méthodes assertNotEquals?

Question

Est-ce que quelqu'un sait pourquoi JUnit 4 fournit assertEquals(foo,bar) mais pas assertNotEqual(foo,bar) méthodes?

Il fournit assertNotSame (correspondant à assertSame ) et assertFalse (correspondant à assertTrue ), donc il semble étrange qu'ils n'aient pas dérangé y compris assertNotEqual .

En passant, je sais que JUnit-addons fournit les méthodes que je cherche. Je demande juste par curiosité.

Answer 1

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)));

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

Pour 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.*;

Answer 2

Il y a un assertNotEquals dans JUnit 4.11: https://github.com/junit-team/junit/blob/master/doc/ReleaseNotes4.11.md#improvements-to-assert-and-assume

Answer 3

Je me demande même, de l'api de l'Assertion n'est pas trop symétrique, parce que pour les essais objets font référence à la même il fournit assertSame et assertNotSame.

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

assertFalse(foo.equals(bar));

Avec une telle affirmation à titre informatif seulement une partie de la production 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

Answer 4

Je dirais que l'absence de assertNotEqual est en effet une asymétrie et fait JUnit un peu moins faciles à apprendre. L'esprit que ce est un joli cas lors de l'ajout d'une méthode permettrait de diminuer la complexité de l'API, au moins pour moi: la Symétrie aide à la décision de la espace plus grand. Ma conjecture est que la raison de l'omission peut être qu'il y a trop peu de gens l'appel de la méthode. Pourtant, je me souviens d'un temps où même assertFalse n'existe pas; par conséquent, j'ai une attente positive que la méthode peut éventuellement être ajouté, étant donné qu'il n'est pas difficile; même si je reconnais qu'il existe de nombreuses solutions de contournement, de même élégant.

Answer 5

Je viens à cette fête assez tard mais j'ai trouvé que le formulaire:

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

peut être fait pour travailler pour la plupart des cas «pas égaux».

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