On Thu, Aug 6, 2009 at 7:04 PM, Mark Hindess <mark.hind...@googlemail.com>wrote:
>
> In message <5948b71e0908052357q5c35d747t14d933e253276...@mail.gmail.com>,
> Charles Lee writes:
> >
> > Hi guys,
> >
> > These days I am writing some testcase to the harmony using Hamcrest. I'd
> > like to introduce harmcrest to the community :-)
> >
> > Hamcrest provides a library of matcher objects (also known as constraints
> or
> > predicates) allowing 'match' rules to be defined declaratively, to be
> used
> > in other frameworks. It maybe the only third-party plugin which junit
> > supports. Check out these beautiful asserts:
> > 1. assertThat(object1, equalTo(object2))
> > 2. assertThat(object1, is(anything()))
> > 3. assertThat(boolean, allOf(boolean1, boolean2)) (like and)
> > 4. assertThat(boolean, anyOf(boolean1, boolean2)) (like or)
> > 5. assertThat(obj1, instanceOf(CLASS))
> > 6. assertThat(obj1, compatibleTo(CLASS))
> > .............
> >
> > Hamcrest makes unit tests more readable. Besides it speed my unit coding
> :-)
>
> While I agree that test readability is important, it is much more
> important that test failure messages be readable/useful because these
> are what we get from a user in a JIRA or in a dev@ message. So examples
> of failure message improvements might make your argument more compelling.
>
> I think most of the Hamcrest core matchers do produce better failure
> output.
>
> As an exmaple of what I am thinking about consider:
>
> org/apache/harmony/luni/tests/java/lang/ThreadTest.java
>
> which contains:
>
> assertTrue("Constructed incorrect thread",
> (st.getThreadGroup() == tg)
> && st.getName().equals("SimpleThread3"));
>
> which is the junit equivalent of the unhelpful code:
>
> if (A or B) System.err.println("Either A or B is broken");
>
> and should probably be written as:
>
> assertEquals("Constructed incorrect thread", tg, st.getThreadGroup());
> assertEquals("Constructed incorrect thread", "SimpleThread3",
> st.getName());
>
> to optimise the failure message(s).
>
> Does hamcrest allOf(...) improve this?
>
The answer is absolutely YES.
> > More detail, please visit Hamcrest <http://code.google.com/p/hamcrest/>.
>
> I assume you are only suggesting using the core matchers in junit 4.4
> rather
> than including a new dependency?
>
> I think some of the other new features[0] in junit 4.4 might be useful too.
> For example, using theories/assumeThat might be a helpful way to cope with
> thinks like:
>
> assumeThat(Test_Support.ipv6_is_enabled());
> ... lots of tests that fail on my non-ipv6 linux/x86_64 machine
>
That's a great feature. I use it as a control to let me run the testcase per
method, since I am lazy to use eclipse.
>
> It might also offer a better approach to excluding tests. Our current
> approach - where we list JIRA numbers in a file - clearly isn't working
> since the exclude files still contain excludes where the corresponding
> JIRA has been closed (despite my complaining about it).
>
> Regards,
> Mark.
>
> [0] http://junit.sourceforge.net/doc/ReleaseNotes4.4.html
>
>
>
--
Yours sincerely,
Charles Lee
