AllOf diagnostics inaccurate about javahamcrest

[sf105]

The message isn't helpful, but the matching appears to be wrong too. You're asserting that the /bean/ has an item, not its strings property, so there's a type failure.

[hertzsprung]

But Bean implements Iterable<String>, so that should be OK, no?

[sf105]

oops. you're right. Missed that

[npryce]

Looks like the hasItem Matcher does not describe a mismatch correctly.

--Nat

On Tuesday, March 12, 2013, James Shaw wrote:

https://gist.github.com/hertzsprung/5141786

Gives me

java.lang.AssertionError:
Expected: (hasProperty("myBoolean", ) and a collection containing "quux")
but: a collection containing "quux"

even though the collection was empty.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/31
.

[scarytom]

Running this example against the trunk of Hamcrest gives the following output:

java.lang.AssertionError: 
Expected: (hasProperty("myBoolean", <true>) and a collection containing "quux")
     but: a collection containing "quux" was empty

There are several fixes in the Hamcrest trunk that have not been released yet. I shall endeavour to push a new release soon (I keep threatening to do this, but somehow never sit down and do it).

[hertzsprung]

That still seems strange to me. How can an empty collection contain
anything? :)
On 13 Mar 2013 19:26, "Tom Denley" [email protected] wrote:

Running this example against the trunk of Hamcrest gives the following
output:

java.lang.AssertionError:
Expected: (hasProperty("myBoolean", ) and a collection containing "quux")
but: a collection containing "quux" was empty

There are several fixes in the Hamcrest trunk that have not been released
yet. I shall endeavour to push a new release soon (I keep threatening to do
this, but somehow never sit down and do it).

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/31#issuecomment-14862879
.[image: Web Bug from
https://github.com/notifications/beacon/IKuIsTejRivtv8yEN00ua_Q8EUxiDL46Oh7ZoalVDntonYGUxFtFvUxfqXq2RGQN.gif]

[scarytom]

This is a behaviour of the allOf matcher: When one of the wrapped matchers fails, it prints first the failing matcher's description, then its mismatch description.

Often a matcher's mismatch description does not uniquely identify it, and so printing that on its own might make it hard for a user to determine which matcher amongst those wrapped in an allOf actually caused the mismatch.

[npryce]

I think it should not print the failing matcher's description alone but add some clarifying text to give context. E.g. 'clause () did not match: .

java.lang.AssertionError: 
Expected: (hasProperty("myBoolean", <true>) and a collection containing "quux")
     but: clause 2 (a collection containing "quux") did not match: was empty

And hasItem should print a better failure description. E.g. "the collection was empty".

[scarytom]

I've been thinking about increasing the descriptiveness of a few of the core matchers, particularly in mismatch scenarios, but I think @sf105 has reasonably strong feelings against increasing the verbosity of the library -- see 96e113d#commitcomment-2308318.

I actually improved this very mismatch to "was an empty collection" but Steve reversed this with e1995a6

I apologise If I'm misrepresenting you Steve, but I would value your opinion on this.

[hertzsprung]

Thanks for the feedback guys.

I've hit this again with some custom matchers; the diagnostics I get are along the lines of "expected object but was object array", rather than "expected object but was array".

If it's not sufficient to print the failing matcher's own mismatch description, then I would favour @npryce 's suggestion. Although, imho, it would read better without any clarifying text because matchers within allOf() tend to check for orthogonal features.

[npryce]

I've just merged a PR that removes the "clarifying" text.