Bug di Hamcrest con o-o e utilizzo nullo o errato?

Question

Sono rimasto scioccato quando qualcosa sulla falsariga di:

assertThat(null, either(is(nullValue())).or(notNullValue())); 

riesce con:

java.lang.AssertionError: 
Expected: (is null or not null) 
    but: was null 
    at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) 
    at org.junit.Assert.assertThat(Assert.java:956) 
    at org.junit.Assert.assertThat(Assert.java:923) 
    at Demo.testName(Demo.java:12) 

Non credo che questo uso è molto insolito (sto effettivamente cercando di affermare la mappa nullo o vuoto) e non riuscivo a trovare qualcosa di sbagliato con il codice sorgente Hamcrest ...

Answer 1

avuto il tempo di fare un po 'di debug.

Il problema è either() genera un CombinableMatcher che si estende TypeSafeDiagnosingMatcher. Quest'ultimo respinge automaticamente null.

IMHO, il parametro tipo di Matcher è in realtà solo un suggerimento, piuttosto che un requisito per cui questo super classe è davvero pericoloso ...

Edit:

Ed ecco un bug report (https://github.com/hamcrest/JavaHamcrest/issues/49). Immagino che non verrà mai riparato ...

Answer 2

uso anyOf

Da Hamcrest tutorials

anyof - le partite se eventuali matchers corrispondono, corto circuiti (come Java ||)

Qualcosa di simile:

assertThat(value, anyOf(equalTo(1), equalTo(2)));