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<ndbe...@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<littlee1...@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 <firep...@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 <littlee1...@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
>>
>
