You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Charles Lee <li...@gmail.com> on 2009/08/06 08:57:15 UTC
Hamcrest
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 :-)
More detail, please visit Hamcrest <http://code.google.com/p/hamcrest/>.
--
Yours sincerely,
Charles Lee
Re: Hamcrest
Posted by Charles Lee <li...@gmail.com>.
On Thu, Aug 6, 2009 at 7:04 PM, Mark Hindess <ma...@googlemail.com>wrote:
>
> In message <59...@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
Re: Hamcrest
Posted by Mark Hindess <ma...@googlemail.com>.
In message <59...@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
Re: Hamcrest
Posted by Sean Qiu <se...@gmail.com>.
If I remember correctly, it is one of the advantage that made us
upgrade our junit from 3.x to 4.4. :-)
So far, I haven't see anyone make advantage of it, but you can take
the initiate.It is pretty cool~
By the way, seems the upcoming new version of junit will bring another
new interesting feature - Per-Test rules[1].
[1] http://www.infoq.com/news/2009/07/junit-4.7-rules
Best Regards
Sean, Xiao Xia Qiu
2009/8/6 Charles Lee <li...@gmail.com>:
> Great News. I have checked the RELEASE NOTES about junit4.4. It seems has
> already include this hamcrest.
> Here is what it said:
>
> Advantages of this assertion syntax include:
>
> -
>
> More readable and typeable: this syntax allows you to think in terms of
> subject, verb, object (assert "x is 3") rather than assertEquals, which
> uses verb, object, subject (assert "equals 3 x")
> -
>
> Combinations: any matcher statement s can be negated (not(s)), combined (
> either(s).or(t)), mapped to a collection (each(s)), or used in custom
> combinations (afterFiveSeconds(s))
> -
>
> Readable failure messages. Compare
>
> assertTrue(responseString.contains("color") ||
> responseString.contains("colour"));
> // ==> failure message:
> // java.lang.AssertionError:
>
>
> assertThat(responseString, anyOf(containsString("color"),
> containsString("colour")));
> // ==> failure message:
> // java.lang.AssertionError:
> // Expected: (a string containing "color" or a string containing "colour")
> // got: "Please choose a font"
>
> -
>
> Custom Matchers. By implementing the Matcher interface yourself, you can
> get all of the above benefits for your own custom assertions.
> -
>
> For a more thorough description of these points, see Joe Walnes's
> original post <http://joe.truemesh.com/blog/000511.html>.
>
> Have fun and enjoy it :-)
>
>
> On Thu, Aug 6, 2009 at 4:05 PM, Jimmy,Jing Lv <fi...@gmail.com> wrote:
>
>> Sounds interesting Charles.
>>
>> I guess it should require more dependence on Hamcrest, which may be some
>> extra cost for building and footprint? So would you please describe what
>> the
>> advantages are, and share your experience? Or share us some examples?
>>
>> 2009/8/6 Charles Lee <li...@gmail.com>
>>
>> > 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
>> > :-)
>> >
>> > More detail, please visit Hamcrest <http://code.google.com/p/hamcrest/>.
>> >
>> > --
>> > Yours sincerely,
>> > Charles Lee
>> >
>>
>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>
>
>
> --
> Yours sincerely,
> Charles Lee
>
Re: Hamcrest
Posted by Nathan Beyer <nb...@gmail.com>.
On Fri, Aug 7, 2009 at 4:22 PM, Mark Hindess<ma...@googlemail.com> wrote:
>
> In message <3b...@mail.gmail.com>,
> Nathan Beyer writes:
>>
>> I updated JUnit to 4.6 and add Hamcrest Library 1.1 (the extra
>> matchers). Everyone will need to do a fetch to get the latest
>> dependencies.
>
> I like this change but had we agreed on this already? I thought the
> discussion was ongoing.
Perhaps. It seems like we've had this conversation a dozen times and
it has always died with "but if we just moved to TestNG life would be
great".
The upgrade to JUnit was something that needed to be done anyway. I
just added the extra library util to push things over the edge. We can
pull that out if no one uses it.
>
>> I didn't add the hamcrest library to all of the unit test compiles or
>> runs. Those can be added as they are needed.
>
> You broke a fresh checkout and build. You renamed junit.jar
> to junit-4.6.jar which is a good idea except that all of the
> -Xbootclasspath/a settings for tests still expect it to be called
> junit.jar. (Tidying up the cleaning of hdk test artifacts is on my
> todo list - which will help catch this kind of problem without a fresh
> checkout.)
>
> I've fixed it by making the copy to the hdk rename the file to junit.jar
> in r802196. This isn't ideal but I'm still working on this area too.
>
I did a clean build, including completely deleting all depends
folders, on Windows x86. I thought everything was referencing the
'${junit.jar}' property, at least that's all I could find with the
various searches I attempted.
Sorry about that. Thanks for cleaning up my mess.
> Regards,
> Mark.
>
>> On Thu, Aug 6, 2009 at 7:24 PM, Nathan Beyer<nd...@apache.org> wrote:
>> > To fully utilize Hamcrest, we just need to bring in the hamcrest lib
>> > dependency to get some of the more useful Matchers or we need to move
>> > to the 'junit-deps' JAR, which includes those Matchers.
>> >
>> > I love the Matchers and using JUnit 4 tests, however, as I recall, one
>> > of the things holding me back from changing tests was that to properly
>> > run JUnit 4 and JUnit 3 tests was that build be run with Ant 1.7+.
>> > That's no longer a concern anymore, so I say it's time to just start
>> > doing it.
>> >
>> > JUnit 4.6 was released recently, so we probably need to upgrade to that a=
>> s well.
>> >
>> > -Nathan
>> >
>> > On Thu, Aug 6, 2009 at 3:17 AM, Charles Lee<li...@gmail.com> wrote:
>> >> Great News. I have checked the RELEASE NOTES about junit4.4. It seems ha=
>> s
>> >> already include this hamcrest.
>> >> Here is what it said:
>> >>
>> >> Advantages of this assertion syntax include:
>> >>
>> >> =C2=A0 -
>> >>
>> >> =C2=A0 More readable and typeable: this syntax allows you to think in te=
>> rms of
>> >> =C2=A0 subject, verb, object (assert "x is 3") rather than assertEquals,=
>> which
>> >> =C2=A0 uses verb, object, subject (assert "equals 3 x")
>> >> =C2=A0 -
>> >>
>> >> =C2=A0 Combinations: any matcher statement s can be negated (not(s)), co=
>> mbined (
>> >> =C2=A0 either(s).or(t)), mapped to a collection (each(s)), or used in cu=
>> stom
>> >> =C2=A0 combinations (afterFiveSeconds(s))
>> >> =C2=A0 -
>> >>
>> >> =C2=A0 Readable failure messages. Compare
>> >>
>> >> =C2=A0 assertTrue(responseString.contains("color") ||
>> >> responseString.contains("colour"));
>> >> =C2=A0 // =3D=3D> failure message:
>> >> =C2=A0 // java.lang.AssertionError:
>> >>
>> >>
>> >> =C2=A0 assertThat(responseString, anyOf(containsString("color"),
>> >> containsString("colour")));
>> >> =C2=A0 // =3D=3D> failure message:
>> >> =C2=A0 // java.lang.AssertionError:
>> >> =C2=A0 // Expected: (a string containing "color" or a string containing =
>> "colour")
>> >> =C2=A0 // =C2=A0 =C2=A0 =C2=A0got: "Please choose a font"
>> >>
>> >> =C2=A0 -
>> >>
>> >> =C2=A0 Custom Matchers. By implementing the Matcher interface yourself, =
>> you can
>> >> =C2=A0 get all of the above benefits for your own custom assertions.
>> >> =C2=A0 -
>> >>
>> >> =C2=A0 For a more thorough description of these points, see Joe Walnes's
>> >> =C2=A0 original post <http://joe.truemesh.com/blog/000511.html>.
>> >>
>> >> Have fun and enjoy it :-)
>> >>
>> >>
>> >> On Thu, Aug 6, 2009 at 4:05 PM, Jimmy,Jing Lv <fi...@gmail.com> wrote=
>> :
>> >>
>> >>> Sounds interesting Charles.
>> >>>
>> >>> I guess it should require more dependence on Hamcrest, which may be som=
>> e
>> >>> extra cost for building and footprint? So would you please describe wha=
>> t
>> >>> the
>> >>> advantages are, and share your experience? Or share us some examples?
>> >>>
>> >>> 2009/8/6 Charles Lee <li...@gmail.com>
>> >>>
>> >>> > 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 constra=
>> ints
>> >>> > 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)) =C2=A0 (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 cod=
>> ing
>> >>> > :-)
>> >>> >
>> >>> > More detail, please visit Hamcrest <http://code.google.com/p/hamcrest=
>> />.
>> >>> >
>> >>> > --
>> >>> > Yours sincerely,
>> >>> > Charles Lee
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>>
>> >>> Best Regards!
>> >>>
>> >>> Jimmy, Jing Lv
>> >>> China Software Development Lab, IBM
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Yours sincerely,
>> >> Charles Lee
>> >>
>> >
>>
>
>
>
Re: Hamcrest
Posted by Mark Hindess <ma...@googlemail.com>.
In message <3b...@mail.gmail.com>,
Nathan Beyer writes:
>
> I updated JUnit to 4.6 and add Hamcrest Library 1.1 (the extra
> matchers). Everyone will need to do a fetch to get the latest
> dependencies.
I like this change but had we agreed on this already? I thought the
discussion was ongoing.
> I didn't add the hamcrest library to all of the unit test compiles or
> runs. Those can be added as they are needed.
You broke a fresh checkout and build. You renamed junit.jar
to junit-4.6.jar which is a good idea except that all of the
-Xbootclasspath/a settings for tests still expect it to be called
junit.jar. (Tidying up the cleaning of hdk test artifacts is on my
todo list - which will help catch this kind of problem without a fresh
checkout.)
I've fixed it by making the copy to the hdk rename the file to junit.jar
in r802196. This isn't ideal but I'm still working on this area too.
Regards,
Mark.
> On Thu, Aug 6, 2009 at 7:24 PM, Nathan Beyer<nd...@apache.org> wrote:
> > To fully utilize Hamcrest, we just need to bring in the hamcrest lib
> > dependency to get some of the more useful Matchers or we need to move
> > to the 'junit-deps' JAR, which includes those Matchers.
> >
> > I love the Matchers and using JUnit 4 tests, however, as I recall, one
> > of the things holding me back from changing tests was that to properly
> > run JUnit 4 and JUnit 3 tests was that build be run with Ant 1.7+.
> > That's no longer a concern anymore, so I say it's time to just start
> > doing it.
> >
> > JUnit 4.6 was released recently, so we probably need to upgrade to that a=
> s well.
> >
> > -Nathan
> >
> > On Thu, Aug 6, 2009 at 3:17 AM, Charles Lee<li...@gmail.com> wrote:
> >> Great News. I have checked the RELEASE NOTES about junit4.4. It seems ha=
> s
> >> already include this hamcrest.
> >> Here is what it said:
> >>
> >> Advantages of this assertion syntax include:
> >>
> >> =C2=A0 -
> >>
> >> =C2=A0 More readable and typeable: this syntax allows you to think in te=
> rms of
> >> =C2=A0 subject, verb, object (assert "x is 3") rather than assertEquals,=
> which
> >> =C2=A0 uses verb, object, subject (assert "equals 3 x")
> >> =C2=A0 -
> >>
> >> =C2=A0 Combinations: any matcher statement s can be negated (not(s)), co=
> mbined (
> >> =C2=A0 either(s).or(t)), mapped to a collection (each(s)), or used in cu=
> stom
> >> =C2=A0 combinations (afterFiveSeconds(s))
> >> =C2=A0 -
> >>
> >> =C2=A0 Readable failure messages. Compare
> >>
> >> =C2=A0 assertTrue(responseString.contains("color") ||
> >> responseString.contains("colour"));
> >> =C2=A0 // =3D=3D> failure message:
> >> =C2=A0 // java.lang.AssertionError:
> >>
> >>
> >> =C2=A0 assertThat(responseString, anyOf(containsString("color"),
> >> containsString("colour")));
> >> =C2=A0 // =3D=3D> failure message:
> >> =C2=A0 // java.lang.AssertionError:
> >> =C2=A0 // Expected: (a string containing "color" or a string containing =
> "colour")
> >> =C2=A0 // =C2=A0 =C2=A0 =C2=A0got: "Please choose a font"
> >>
> >> =C2=A0 -
> >>
> >> =C2=A0 Custom Matchers. By implementing the Matcher interface yourself, =
> you can
> >> =C2=A0 get all of the above benefits for your own custom assertions.
> >> =C2=A0 -
> >>
> >> =C2=A0 For a more thorough description of these points, see Joe Walnes's
> >> =C2=A0 original post <http://joe.truemesh.com/blog/000511.html>.
> >>
> >> Have fun and enjoy it :-)
> >>
> >>
> >> On Thu, Aug 6, 2009 at 4:05 PM, Jimmy,Jing Lv <fi...@gmail.com> wrote=
> :
> >>
> >>> Sounds interesting Charles.
> >>>
> >>> I guess it should require more dependence on Hamcrest, which may be som=
> e
> >>> extra cost for building and footprint? So would you please describe wha=
> t
> >>> the
> >>> advantages are, and share your experience? Or share us some examples?
> >>>
> >>> 2009/8/6 Charles Lee <li...@gmail.com>
> >>>
> >>> > 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 constra=
> ints
> >>> > 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)) =C2=A0 (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 cod=
> ing
> >>> > :-)
> >>> >
> >>> > More detail, please visit Hamcrest <http://code.google.com/p/hamcrest=
> />.
> >>> >
> >>> > --
> >>> > Yours sincerely,
> >>> > Charles Lee
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Best Regards!
> >>>
> >>> Jimmy, Jing Lv
> >>> China Software Development Lab, IBM
> >>>
> >>
> >>
> >>
> >> --
> >> Yours sincerely,
> >> Charles Lee
> >>
> >
>
Re: Hamcrest
Posted by Nathan Beyer <nd...@apache.org>.
I updated JUnit to 4.6 and add Hamcrest Library 1.1 (the extra
matchers). Everyone will need to do a fetch to get the latest
dependencies.
I didn't add the hamcrest library to all of the unit test compiles or
runs. Those can be added as they are needed.
-Nathan
On Thu, Aug 6, 2009 at 7:24 PM, Nathan Beyer<nd...@apache.org> wrote:
> To fully utilize Hamcrest, we just need to bring in the hamcrest lib
> dependency to get some of the more useful Matchers or we need to move
> to the 'junit-deps' JAR, which includes those Matchers.
>
> I love the Matchers and using JUnit 4 tests, however, as I recall, one
> of the things holding me back from changing tests was that to properly
> run JUnit 4 and JUnit 3 tests was that build be run with Ant 1.7+.
> That's no longer a concern anymore, so I say it's time to just start
> doing it.
>
> JUnit 4.6 was released recently, so we probably need to upgrade to that as well.
>
> -Nathan
>
> On Thu, Aug 6, 2009 at 3:17 AM, Charles Lee<li...@gmail.com> wrote:
>> Great News. I have checked the RELEASE NOTES about junit4.4. It seems has
>> already include this hamcrest.
>> Here is what it said:
>>
>> Advantages of this assertion syntax include:
>>
>> -
>>
>> More readable and typeable: this syntax allows you to think in terms of
>> subject, verb, object (assert "x is 3") rather than assertEquals, which
>> uses verb, object, subject (assert "equals 3 x")
>> -
>>
>> Combinations: any matcher statement s can be negated (not(s)), combined (
>> either(s).or(t)), mapped to a collection (each(s)), or used in custom
>> combinations (afterFiveSeconds(s))
>> -
>>
>> Readable failure messages. Compare
>>
>> assertTrue(responseString.contains("color") ||
>> responseString.contains("colour"));
>> // ==> failure message:
>> // java.lang.AssertionError:
>>
>>
>> assertThat(responseString, anyOf(containsString("color"),
>> containsString("colour")));
>> // ==> failure message:
>> // java.lang.AssertionError:
>> // Expected: (a string containing "color" or a string containing "colour")
>> // got: "Please choose a font"
>>
>> -
>>
>> Custom Matchers. By implementing the Matcher interface yourself, you can
>> get all of the above benefits for your own custom assertions.
>> -
>>
>> For a more thorough description of these points, see Joe Walnes's
>> original post <http://joe.truemesh.com/blog/000511.html>.
>>
>> Have fun and enjoy it :-)
>>
>>
>> On Thu, Aug 6, 2009 at 4:05 PM, Jimmy,Jing Lv <fi...@gmail.com> wrote:
>>
>>> Sounds interesting Charles.
>>>
>>> I guess it should require more dependence on Hamcrest, which may be some
>>> extra cost for building and footprint? So would you please describe what
>>> the
>>> advantages are, and share your experience? Or share us some examples?
>>>
>>> 2009/8/6 Charles Lee <li...@gmail.com>
>>>
>>> > 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
>>> > :-)
>>> >
>>> > More detail, please visit Hamcrest <http://code.google.com/p/hamcrest/>.
>>> >
>>> > --
>>> > Yours sincerely,
>>> > Charles Lee
>>> >
>>>
>>>
>>>
>>> --
>>>
>>> Best Regards!
>>>
>>> Jimmy, Jing Lv
>>> China Software Development Lab, IBM
>>>
>>
>>
>>
>> --
>> Yours sincerely,
>> Charles Lee
>>
>
Re: Hamcrest
Posted by Nathan Beyer <nd...@apache.org>.
To fully utilize Hamcrest, we just need to bring in the hamcrest lib
dependency to get some of the more useful Matchers or we need to move
to the 'junit-deps' JAR, which includes those Matchers.
I love the Matchers and using JUnit 4 tests, however, as I recall, one
of the things holding me back from changing tests was that to properly
run JUnit 4 and JUnit 3 tests was that build be run with Ant 1.7+.
That's no longer a concern anymore, so I say it's time to just start
doing it.
JUnit 4.6 was released recently, so we probably need to upgrade to that as well.
-Nathan
On Thu, Aug 6, 2009 at 3:17 AM, Charles Lee<li...@gmail.com> wrote:
> Great News. I have checked the RELEASE NOTES about junit4.4. It seems has
> already include this hamcrest.
> Here is what it said:
>
> Advantages of this assertion syntax include:
>
> -
>
> More readable and typeable: this syntax allows you to think in terms of
> subject, verb, object (assert "x is 3") rather than assertEquals, which
> uses verb, object, subject (assert "equals 3 x")
> -
>
> Combinations: any matcher statement s can be negated (not(s)), combined (
> either(s).or(t)), mapped to a collection (each(s)), or used in custom
> combinations (afterFiveSeconds(s))
> -
>
> Readable failure messages. Compare
>
> assertTrue(responseString.contains("color") ||
> responseString.contains("colour"));
> // ==> failure message:
> // java.lang.AssertionError:
>
>
> assertThat(responseString, anyOf(containsString("color"),
> containsString("colour")));
> // ==> failure message:
> // java.lang.AssertionError:
> // Expected: (a string containing "color" or a string containing "colour")
> // got: "Please choose a font"
>
> -
>
> Custom Matchers. By implementing the Matcher interface yourself, you can
> get all of the above benefits for your own custom assertions.
> -
>
> For a more thorough description of these points, see Joe Walnes's
> original post <http://joe.truemesh.com/blog/000511.html>.
>
> Have fun and enjoy it :-)
>
>
> On Thu, Aug 6, 2009 at 4:05 PM, Jimmy,Jing Lv <fi...@gmail.com> wrote:
>
>> Sounds interesting Charles.
>>
>> I guess it should require more dependence on Hamcrest, which may be some
>> extra cost for building and footprint? So would you please describe what
>> the
>> advantages are, and share your experience? Or share us some examples?
>>
>> 2009/8/6 Charles Lee <li...@gmail.com>
>>
>> > 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
>> > :-)
>> >
>> > More detail, please visit Hamcrest <http://code.google.com/p/hamcrest/>.
>> >
>> > --
>> > Yours sincerely,
>> > Charles Lee
>> >
>>
>>
>>
>> --
>>
>> Best Regards!
>>
>> Jimmy, Jing Lv
>> China Software Development Lab, IBM
>>
>
>
>
> --
> Yours sincerely,
> Charles Lee
>
Re: Hamcrest
Posted by Charles Lee <li...@gmail.com>.
Great News. I have checked the RELEASE NOTES about junit4.4. It seems has
already include this hamcrest.
Here is what it said:
Advantages of this assertion syntax include:
-
More readable and typeable: this syntax allows you to think in terms of
subject, verb, object (assert "x is 3") rather than assertEquals, which
uses verb, object, subject (assert "equals 3 x")
-
Combinations: any matcher statement s can be negated (not(s)), combined (
either(s).or(t)), mapped to a collection (each(s)), or used in custom
combinations (afterFiveSeconds(s))
-
Readable failure messages. Compare
assertTrue(responseString.contains("color") ||
responseString.contains("colour"));
// ==> failure message:
// java.lang.AssertionError:
assertThat(responseString, anyOf(containsString("color"),
containsString("colour")));
// ==> failure message:
// java.lang.AssertionError:
// Expected: (a string containing "color" or a string containing "colour")
// got: "Please choose a font"
-
Custom Matchers. By implementing the Matcher interface yourself, you can
get all of the above benefits for your own custom assertions.
-
For a more thorough description of these points, see Joe Walnes's
original post <http://joe.truemesh.com/blog/000511.html>.
Have fun and enjoy it :-)
On Thu, Aug 6, 2009 at 4:05 PM, Jimmy,Jing Lv <fi...@gmail.com> wrote:
> Sounds interesting Charles.
>
> I guess it should require more dependence on Hamcrest, which may be some
> extra cost for building and footprint? So would you please describe what
> the
> advantages are, and share your experience? Or share us some examples?
>
> 2009/8/6 Charles Lee <li...@gmail.com>
>
> > 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
> > :-)
> >
> > More detail, please visit Hamcrest <http://code.google.com/p/hamcrest/>.
> >
> > --
> > Yours sincerely,
> > Charles Lee
> >
>
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>
--
Yours sincerely,
Charles Lee
Re: Hamcrest
Posted by "Jimmy,Jing Lv" <fi...@gmail.com>.
Sounds interesting Charles.
I guess it should require more dependence on Hamcrest, which may be some
extra cost for building and footprint? So would you please describe what the
advantages are, and share your experience? Or share us some examples?
2009/8/6 Charles Lee <li...@gmail.com>
> 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
> :-)
>
> More detail, please visit Hamcrest <http://code.google.com/p/hamcrest/>.
>
> --
> Yours sincerely,
> Charles Lee
>
--
Best Regards!
Jimmy, Jing Lv
China Software Development Lab, IBM