Comments (6)
Today I also was puzzled why assertThat(null, either(is(something)).or(nullValue()))
did yield an AssertionError
.
But I think this can't be easily fixed easily because the JavaDoc of TypeSafeDiagnosingMatcher
explicitly states that null
is checked by TypeSafeDiagnosingMatcher
and won't be passed to matchesSafely
, cf. the JavaDoc. So a change of this would result in a breaking change for existing code. But I agree that this is confusing and maybe an eitherNull().or()
construct or even something more pluggable would be great to have.
from javahamcrest.
Proposed a solution here: #56
from javahamcrest.
If that's the behaviour you want, then you probably want a different matcher. The point of a TypeSafe matcher is that confirms that the actual value has the right type, which null doesn't.
I'm also wondering about the use case for "either something or null" in an assertion. Surely you know which one is appropriate when you write the test?
from javahamcrest.
Maybe the fact that one wants to use either(equalTo(something)).or(nullValue())
might be a hint that the design or the API has some problems. But sometimes I also felt the need to use the matcher in this way and was surprised that either(equalTo(something)).or(nullValue())
didn't match even though my code returned null
.
One idea might be to add a mismatch description to TypeSafeDiagnosingMatcher
when null
is passed to matches()
so that it is more obvious for users of Matchers inheriting why the matcher doesn't match null
.
from javahamcrest.
It's up to the assertion calling the matcher to report the actual value. In this case, I would expect it to show the null
.
from javahamcrest.
This is caused by this little pice of code in TypeSafeDiagnosingMatcher
@Override
@SuppressWarnings("unchecked")
public final boolean matches(Object item) {
return item != null
&& expectedType.isInstance(item)
&& matchesSafely((T) item, new Description.NullDescription());
}
The item != null
and expectedType.isInstance(item)
is false for item = null
This can be fixed by adding this dirty hack to CombinableMatcher
@Override
public final boolean matches(Object item) {
if(this.matcher instanceof AnyOf)
{
AnyOf anyOf = (AnyOf) this.matcher;
List<Matcher<T>> matchers = (List<Matcher<T>>) anyOf.getMatchers();
Boolean matches = false;
for(Matcher eachMatcher : matchers)
{
if(eachMatcher.matches(item))
{
matches = true;
}
}
return matches;
}
else {
return super.matches(item);
}
}
Therefore TypeSafeDiagnosingMatcher's matches method must be non final and ShortcutCombination needs a getter for matchers.
I know this is really dirty, maybe someone can make a fix with this information. I'll also try to write a better fix for that.
EDIT:
I also wrote a test
private static final CombinableMatcher<String> EMPTY_STRING_OR_NULL = CombinableMatcher.either(equalTo("")).or(nullValue());
@Test public void
acceptNullOrEmptyString() {
assertMatches("or didn't pass", EMPTY_STRING_OR_NULL, null);
assertMatches("either didn't pass", EMPTY_STRING_OR_NULL, "");
}
from javahamcrest.
Related Issues (20)
- containsInAnyOrder incorrectly identifies differences in identical collections HOT 1
- Hamcrest 3.0? HOT 2
- You should be able to specify a lambda to return a reason
- Conflicting license declarations HOT 1
- Not sure why assertThat() doesn't work in this case HOT 2
- 301 Moved Permanently
- assertThat(this.object, hasProperty("booleanName")) fails to match boolean types and renames the property HOT 1
- The matcher contains() is misleading HOT 2
- FR: Matching maps with various type HOT 1
- oss-fuzz integration
- Participitation in Hacktoberfest?
- HasProperty Matcher doesn't work with Java Records HOT 1
- assertThat(Int::class.java, typeCompatibleWith(Number::class.java)) in kotlin always fails
- hamcrest matching on actual empty list fails with nosuchmethoderror HOT 1
- Test output Alignment
- record version fails the hasProperty HOT 1
- has property fails with non public class.. not sure if this correct as per java standards of property
- Double "close-to" matcher that uses the ULP.
- GraalVM Native Image support HOT 3
- Inquiry about Project Activity and Future Plans HOT 13
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from javahamcrest.