First Functionality

Applying the recipe from Chapter 3, I jumped immediately into the happy path. The purpose of the application is to retrieve content from URLs. The simplest happy path retrieves content from a single URL. I defined the basic retrieve() method through its test (Listing 14-1).

Listing 14-1: Defining a simple retrieve() method by using it in its test [0c2d67e]. This “fails” because the method does not exist.

Click here to view code image

@Test
public void testRetrieve_SingleURI() {
  WebRetriever sut = new WebRetriever();

  String content = sut.retrieve("http://www.example.com");
}

For now, in the spirit of YAGNI, the simplest implementation takes the URL and returns the retrieved content as strings, deferring the questions of command-line arguments and output.

Over the next several commits, up to [839e4dc], we evolve the test so that it expresses our full intent and the implementation so that it passes. At this point, the test needs to be strengthened, as it relies only on containment. By most definitions, the test does not qualify as a unit test because it opens a socket to a web page as well. However, in the interest of getting it working first, this represents good progress. I used the Apache HttpClient library to avoid writing the entire protocol myself. After all, test driving does not mean you should reinvent everything.

In the process of manually exploring to ensure that my test data was appropriate, I discovered that the test URL actually uses an HTTP 302 response to redirect to a different host. The HttpClient library handles this transparently to the calling code, a behavior in which WebRetriever operates differently from curl. One of the benefits of a goal of creating work-alike software is the availability of the original as your benchmark. I will ignore this difference, although curl’s behavior was essential in discovering the redirect.

A few refactoring commits up through [1b49d37] bring us to the first significant testability changes.