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?
> 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
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
