hardayal / hamcrest

Automatically exported from code.google.com/p/hamcrest
0 stars 0 forks source link

TypeSafeDiagnosingMatcher discards Description #108

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
To use TypeSafeDiagnosingMatcher, the javadoc says code should extend 
matchesSafely(T, Description). However, the code that calls this method passes 
a NullDescription as the Description object, which then discards anything that 
is given. 

In my particular scenario, I have a custom matcher (extends 
CustomTypeSafeMatcher) which is passed into the Every matcher, which extends 
the TypeSafeDiagnosingMatcher class. When one of the matchers fails, this 
NullDescription method is passed into my class and I have no way of describing 
which of the elements of the collection fails to match.

The code which doesn't look correct in TypeSafeDignosingMatcher follows:
    @SuppressWarnings("unchecked")
    public final boolean matches(Object item) {
        return item != null
            && expectedType.isInstance(item)
            && matchesSafely((T) item, new Description.NullDescription());
    }

My only thought is that I should be calling a different method, but I can't 
imagine what.

Original issue reported on code.google.com by shawn.la...@gmail.com on 7 Jun 2010 at 8:42

GoogleCodeExporter commented 8 years ago
When matchesSafely() returns false, assertThat() calls describeMismatch() to 
get the description of what didn't match. TypeSafeDiagnosingMatcher overrides 
describeMismatch() and calls matchesSafely() again, this time passing in 
mismatchDescription which was given to it by assertThat().

The other option would have been to separate matchesSafely() in 
TypeSafeDiagnosingMatcher and TypeSafeMatcher into matchesSafely() and 
describeMismatchSafely(), but it doesn't make much difference. In one call you 
build a description that will be ignored, and in the other you perform a 
comparison whose result will be ignored, but you'd probably have to have the 
comparison logic in describeMismatchSafely() anyway.

Of course that begs the question, why does performing a type-safe match require 
a different design? :)

As to your issue, are you saying that your custom matcher's mismatch 
description created in matchesSafely() isn't being displayed? Or are you merely 
inspecting the TypeSafeDiagnosingMatcher code and not seeing how it *will* work 
once implemented?

Original comment by dharkn...@gmail.com on 27 Jul 2010 at 9:30

GoogleCodeExporter commented 8 years ago
I'm trying to use HasPropertyWithValue matcher in a following way:

assertThat(trade, hasProperty("currency", equalTo("USD1")));

However, when property doesn't match there is no description generated by 
hasProperty and equalTo matchers, I get:

java.lang.AssertionError: 
Expected: hasProperty("currency", "USD")
     got: <Trade ... here goes trade.toString() output

But what I want to see is smth like "got: property 'currency' = EUR", i.e., 
description returned by hasProperty and equalTo matchers. I see in code that 
TypeSafeDiagnosingMatcher passes Description.NullDescription() to 
matchesSafely(), so nested matchers have no chance to write the description.

I think this issue was created due to the same problem as I describe. Maybe 
there is another way of using HasPropertyWithValue matcher?

Original comment by kazantse...@gmail.com on 6 Feb 2012 at 1:55

GoogleCodeExporter commented 8 years ago
I also had the same problems. Resolved it by using Hamcrest's Assert.assertThat 
instead of JUnit's.

Original comment by ketil.aa...@gmail.com on 18 Mar 2013 at 5:28