Mastering JUnit - JUnit in Action - page 32

3.2.2 Adding a handler

Now that you have a bootstrap test, the next step is to decide what to test first. We
started the test case with the DefaultController object, because that's the point of
this exercise: to create a controller. You wrote some code and made sure it compiled.
But how can you test to see if it works?
The purpose of the controller is to process a request and return a response. But
before you process a request, the design calls for adding a RequestHandler to do the
processing. So, first things first: you should test whether you can add a RequestHandler .
The tests you ran in chapter 1 returned a known result. To see if a test succeeded,
you compared the result you expected with whatever result the object you were testing
returned. The signature for addHandler is

void addHandler(Request request, RequestHandler requestHandler)
To add a RequestHandler , you need a Request with a known name. To check to see if
adding it worked, you can use the getHandler method from DefaultController ,
which uses this signature:

RequestHandler getHandler(Request request)
This is possible because the getHandler method is protected, and the test classes are
located in the same package as the classes they're testing. This is one reason to define
the tests under the same package.
For the first test, it looks like you can do the following:
■ Add a RequestHandler , referencing a Request .
■ Get a RequestHandler and pass the same Request .
■ Check to see if you get the same RequestHandler back.
W HERE DO TESTS COME FROM ?
Now you know what objects you need. The next question is, “Where do these objects
come from?” Should you go ahead and write some of the objects you'll use in the
application, such as a logon request?
The point of unit testing is to test one object at a time. In an object-oriented envi-
ronment like Java, you design objects to interact with other objects. To create a unit
test, it follows that you need two flavors of objects: the domain object you're testing and
test objects to interact with the object under test.

DEFINITION Domain object —In the context of unit testing, the term domain
object is used to contrast and compare the objects you use in your application
with the objects that you use to test your application ( test objects ). Any object
under test is considered a domain object.

If you used another domain object, like a logon request, and a test failed, it would be
hard to identify the culprit. You might not be able to tell whether the problem was with
the controller or the request. So, in the first series of tests, the only class you'll use in
production is DefaultController . Everything else should be a special test class.