assertThat() failure output doesn't allow Matcher to describe the mismatch

[beckymc22]

Hi,

I recently upgraded to JUnit 4 and started exploring Matchers. I found that the org.junit.Assert.assertThat() method doesn't allow my Matcher's describeMismatch() method to influence the 2nd part of the failure output (the "got:" part), in my case it's not a String:

java.lang.AssertionError:
Expected: a CDR record with call ID: 12345678900
     got: <org.cafesip.sipexchange.ejbs.cdr.value.CdrRecord@1712b3a>

        at org.junit.Assert.assertThat(Assert.java:778)
        at org.junit.Assert.assertThat(Assert.java:736)
        at org.cafesip.sipexchange.ejbs.cdr.tests.CdrServiceTest.testCdrCreation
(CdrServiceTest.java:154)


I think I see the reason for it in the code:

        public static <T> void assertThat(String reason, T actual,
                        Matcher<T> matcher) {
                if (!matcher.matches(actual)) {
                        Description description= new StringDescription();
                        description.appendText(reason);
                        description.appendText("\nExpected: ");
                        description.appendDescriptionOf(matcher);
                        description.appendText("\n     got: ");
                        description.appendValue(actual);
                        description.appendText("\n");
                        throw new java.lang.AssertionError(description.toString());
                }
        }


But if I use the hamcrest assertThat() method, it calls my Matcher's describeMatch() method and I get something more useful:

java.lang.AssertionError:
Expected: a CDR record with call ID: 12345678900
     but: the call ID was "1234567890"
        at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
        at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
        at org.cafesip.sipexchange.ejbs.cdr.tests.CdrServiceTest.testCdrCreation
(CdrServiceTest.java:154)


Did I miss something in using the JUnit version of assertThat? Or, it's not all there yet?

Thanks,
Becky

[kentb]

Can you file this as a defect? We'd appreciate the test that, when passing,
will demonstrate that we're doing the right thing.
 
Kent

  _____  

From: junit@... [mailto:junit@...] On Behalf Of
beckymc22
Sent: Saturday, September 19, 2009 3:13 PM
To: junit@...
Subject: [junit] assertThat() failure output doesn't allow Matcher to
describe the mismatch


 

Hi,

I recently upgraded to JUnit 4 and started exploring Matchers. I found that
the org.junit.Assert.assertThat() method doesn't allow my Matcher's
describeMismatch() method to influence the 2nd part of the failure output
(the "got:" part), in my case it's not a String:

java.lang.AssertionError:
Expected: a CDR record with call ID: 12345678900
got: <org.cafesip.sipexchange.ejbs.cdr.value.CdrRecord@1712b3a>

at org.junit.Assert.assertThat(Assert.java:778)
at org.junit.Assert.assertThat(Assert.java:736)
at org.cafesip.sipexchange.ejbs.cdr.tests.CdrServiceTest.testCdrCreation
(CdrServiceTest.java:154)

I think I see the reason for it in the code:

public static <T> void assertThat(String reason, T actual,
Matcher<T> matcher) {
if (!matcher.matches(actual)) {
Description description= new StringDescription();
description.appendText(reason);
description.appendText("\nExpected: ");
description.appendDescriptionOf(matcher);
description.appendText("\n got: ");
description.appendValue(actual);
description.appendText("\n");
throw new java.lang.AssertionError(description.toString());
}
}

But if I use the hamcrest assertThat() method, it calls my Matcher's
describeMatch() method and I get something more useful:

java.lang.AssertionError:
Expected: a CDR record with call ID: 12345678900
but: the call ID was "1234567890"
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8)
at org.cafesip.sipexchange.ejbs.cdr.tests.CdrServiceTest.testCdrCreation
(CdrServiceTest.java:154)

Did I miss something in using the JUnit version of assertThat? Or, it's not
all there yet?

Thanks,
Becky






[Non-text portions of this message have been removed]