Coarse-grained testing with stubs - JUnit in Action - page 95

6.3.3 Reviewing the first stub test

You've now been able to fully unit test the getContent method in isolation by stub-
bing the web resource. What have you really tested? What kind of test have you
achieved? You've done something quite powerful: you've unit tested the method, but
at the same time, you've executed an integration test. In addition, not only have you
tested the code logic, but you've also tested the connection part that's outside the
code (through the Java HttpURLConnection class).
The drawback to this approach is that it's complex. It can take a Jetty novice half a
day to learn enough about Jetty to set it up correctly. In some instances, you'll have to
debug stubs to get them to work properly. Keep in mind that the stub must remain
simple and not become a full-fledged application that requires tests and mainte-
nance. If you spend too much time debugging your stubs, a different solution may be
called for.
In these examples, you need a web server—but another example and stub will be
different and will need a different setup. Experience helps, but different cases usually
require different stubbing solutions.
The example tests are nice because you can both unit test the code and perform
some integration tests at the same time. But this functionality comes at the cost of
complexity. More solutions that are lightweight focus on unit testing the code without
performing integration tests. The rationale is that although you need integration
tests, they could run in a separate test suite or as part of functional tests.
In the next section, we look at another solution that can still qualify as stubbing.
It's simpler in the sense that it doesn't require you to stub a whole web server. It
brings you one step closer to the mock object strategy, which is described in the fol-
lowing chapter.

6.4 Stubbing the connection

So far, you've stubbed the web server's resources. Next, we stub the HTTP connection
instead. Doing so will prevent you from effectively testing the connection, but that's
fine because it isn't your real goal at this point. You want to test your code in isolation.
Functional or integration tests will test the connection at a later stage.
When it comes to stubbing the connection without changing the code, we benefit
from Java's URL and HttpURLConnection classes, which let us plug in custom protocol
handlers to process any kind of communication protocol. You can have any call to the
HttpURLConnection class redirected to your own class, which will return whatever you
need for the test.

6.4.1 Producing a custom URL protocol handler

To i m p l e m e n t a c u s t o m URL protocol handler, you need to call the URL method set-
URLStreamHandlerFactory and pass it a custom URLStreamHandlerFactory . When-
ever the URL openConnection method is called, the URLStreamHandlerFactory class is
called to return a URLStreamHandler . Listing 6.6 shows the code to perform this feat.