harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hindess <mark.hind...@googlemail.com>
Subject Re: Hamcrest
Date Thu, 06 Aug 2009 11:04:05 GMT

In message <5948b71e0908052357q5c35d747t14d933e253276d59@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

As an exmaple of what I am thinking about consider:


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:

  ... 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).


[0] http://junit.sourceforge.net/doc/ReleaseNotes4.4.html

View raw message