Mastering JUnit - JUnit in Action - page 30

return this .originalRequest;
}
public Exception getOriginalException()
{
return this.originalException;
}
}
At this point, you have a crude but effective skeleton for the controller. Table 3.1
shows how the requirements at the top of this section relate to the source code.

Table 3.1 Resolving the base requirements for the component

Requirement Resolution

Accept requests

public Response processRequest(Request request)

Select handler

this.requestHandlers.get(request.getName())

Route requests

response = getRequestHandler(request).process(request);

Error handling

Subclass ErrorResponse

The next step for many developers would be to cobble up a stub application to go
with the skeleton controller. As test-infected developers, we can write a test suite
for the controller without fussing with a stub application. That's the beauty of unit
testing. We can write a package and verify that it works, all outside a conventional
Java application.

3.2 Let's test it!

A fit of inspiration has led us to code the four interfaces shown in listing 3.1 and the
two starter classes shown in listings 3.2 and 3.3. If we don't write an automatic test now,
the Bureau of Extreme Programming will be asking for our membership cards back!
Listings 3.2 and 3.3 began with the simplest implementations possible. Let's do
the same with the new set of unit tests. What's the simplest-possible test case we
can explore?

3.2.1 Testing the DefaultController

How about a test case that instantiates the DefaultController class? The first step
in doing anything useful with the controller is to construct it, so let's start there.
Listing 3.4 shows the bootstrap test code. It constructs the DefaultController
object and sets up a framework for writing tests.

Listing 3.4 TestDefaultController —a bootstrap iteration

[...]
import org.junit.core.Test;
import static org.junit.Assert.*;