Perché JUnit non fornisce i metodi assertNotEquals?

Question

Qualcuno sa perché JUnit 4 fornisce i metodi assertEquals(foo,bar) ma non ?

Fornisce assertNotSame (corrispondente a assertSame) e assertFalse (corrispondenti a assertTrue), così sembra strano che non hanno disturbato compreso assertNotEqual.

A proposito, so che JUnit-addons fornisce i metodi che sto cercando. Sto solo chiedendo per curiosità.

Answer 1

Io suggerirei di usare il più recente assertThat() stile asserisce, che può facilmente descrivere tutti i tipi di negazioni e di costruire una descrizione di quello che ti aspettavi e che cosa avete ottenuto automaticamente se l'asserzione non va a buon fine:

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

Tutte e tre le opzioni sono equivalenti, scegliere quella che si trova più leggibile.

Per utilizzare i semplici nomi dei metodi (e consentire questa sintassi teso al lavoro), è necessario che tali importazioni:

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

Answer 2

Mi chiedo lo stesso. L'API di Assert non è molto simmetrica; per verificare se gli oggetti sono uguali, fornisce assertSame e assertNotSame.

Naturalmente, non è troppo tempo per scrivere:

assertFalse(foo.equals(bar)); 

Con tale affermazione, l'unica parte informativa della produzione è, purtroppo, il nome del metodo di prova, messaggio in modo descrittivo dovrebbe essere formato separatamente :

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

Questo è, naturalmente, in modo noioso, che è meglio per rotolare il proprio assertNotEqual. Per fortuna in futuro sarà forse parte della JUnit: JUnit issue 22

Answer 3

E 'meglio usare la Hamcrest in quelle negative, piuttosto che assertFalse come nel primo il rapporto di prova mostrerà una diff per l'errore di asserzione.

Se si utilizza assertFalse, si ottiene solo un errore di asserzione nel report. cioè informazioni perse sulla causa dell'errore.

Answer 4

Direi che l'assenza di assertNotEqual è davvero un'asimmetria e rende JUnit un po 'meno apprendibile. Ricorda che questo è un caso preciso quando l'aggiunta di un metodo ridurrebbe la complessità dell'API, almeno per me: Symmetry aiuta a governare lo spazio più grande. La mia ipotesi è che il motivo dell'omissione potrebbe essere che ci sono troppe poche persone che chiedono il metodo. Tuttavia, ricordo un tempo in cui persino False affermava che non esisteva; quindi, ho un'aspettativa positiva che il metodo possa eventualmente essere aggiunto, dato che non è difficile; anche se riconosco che ci sono numerosi soluzioni alternative, anche eleganti.

Answer 5

Vengo a questo partito piuttosto tardi, ma ho scoperto che la forma:

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

può essere fatto per lavorare per la maggior parte 'non è uguale a' casi.

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

Answer 6

C'è un 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 7

L'ovvia ragione che la gente voleva assertNotEquals() è stato quello di confrontare i comandi incorporati senza doverli convertire in oggetti in piena regola per prime:

Esempio dettagliato:

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

vs

assertNotEqual(1, winningBidderId); 

Purtroppo dal momento che Eclipse non include JUnit 4.11 per impostazione predefinita è necessario essere prolisso.

Avvertenza: non credo che il '1' debba essere racchiuso in un valore Integer.valueOf(), ma dal momento che sono appena ritornato da .NET non conta sulla mia correttezza.

Answer 8

Modulo consistenza API, perché JUnit non ha fornito assertNotEquals() è la stessa ragione per cui JUnit non disponibile metodi come

• assertStringMatchesTheRegex(regex, str) vs. assertStringDoesntMatchTheRegex(regex, str)
• assertStringBeginsWith(prefix, str) vs. assertStringDoesntBeginWith(prefix, str)

cioè c'è non c'è limite alla fornitura di metodi di asserzione specifici per il tipo di cose che potresti desiderare nella tua logica di asserzione!

Molto meglio per fornire le primitive di prova componibile come equalTo(...), is(...), not(...), regex(...) e lasciare che il pezzo programmatore quelli insieme invece per più leggibilità e la sanità mentale.

Answer 9

Sto lavorando su JUnit in Java 8 ambiente, utilizzando jUnit4.12

per me: il compilatore non era in grado di trovare le assertNotEquals metodo, anche quando ho usato
import org.junit.Assert;

Così ho cambiato
assertNotEquals("addb", string);
a
Assert.assertNotEquals("addb", string);

quindi, se si trovano ad affrontare problema per quanto riguarda assertNotEqual non riconosciuto, quindi, trasformarlo in Assert.assertNotEquals(,); dovrebbe risolvere il tuo problema