harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charles Lee <littlee1...@gmail.com>
Subject Re: Hamcrest
Date Fri, 07 Aug 2009 02:24:18 GMT
On Thu, Aug 6, 2009 at 7:04 PM, Mark Hindess <mark.hindess@googlemail.com>wrote:

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message