Mastering JUnit - JUnit in Action - page 50

Table 3.2 Some of the most commonly used Hamcrest matchers (continued)

Core Logical

sameInstance

Tests object identity.

notNullValue, nullValue

Tests for null values (or non-null values).

Tests whether a JavaBean has a certain property.

hasProperty

hasEntry, hasKey, hasValue

Tests whether a given Map has a given entry,
key, or value.

hasItem, hasItems

Tests a given collection for the presence of an
item or items.

closeTo, greaterThan,
greaterThanOrEqual, lessThan,
lessThanOrEqual

Test whether given numbers are close to, greater
than, greater than or equal to, less than, or less
than or equal to a given value.

equalToIgnoringCase

Tests whether a given string equals another one,
ignoring the case.

equalToIgnoringWhiteSpace

Tests whether a given string equals another one,
by ignoring the white spaces.

containsString, endsWith, startWith Test whether the given string contains, starts
with, or ends with a certain string.

All of them seem straightforward to read and use, and remember that you can com-
bine them with each other.
Finally, Hamcrest is extremely extensible. It's easy to write your own matchers that
check a certain condition. The only thing you need to do is implement the Matcher
interface and an appropriately named factory method. You can find more on how to
write custom matchers in appendix D of this topic, where we provide a complete over-
view of how to write your own matchers.

3.6 Setting up a project for testing

Because this chapter covers testing a realistic component, let's finish up by looking at
how you set up the controller package as part of a larger project. In chapter 1, you
kept all the Java domain code and test code in the same folder.
They were introductory tests on an example class, so this approach seemed sim-
plest for everyone. In this chapter, you've begun to build real classes with real tests, as
you would for one of your own projects. Accordingly, you've set up the source code
repository as you would for a real project.
So far, you have only one test case. Mixing this in with the domain classes would
not have been a big deal. But experience tells us that soon you'll have at least as many
test classes as you have domain classes. Placing all of them in the same directory will
begin to create file-management issues. It will become difficult to find the class you
want to edit next.