Chapter 14. Test-Driven Java

The first example demonstrates the use of test-driven development to create a new application in Java. I call the project WebRetriever; it is basically a work-alike of a subset of the command-line curl(1)¹ command found in most Linux distributions and Mac OS X. If you are not familiar with curl, it is a tool for retrieving content over the internet that can be specified as URIs, including authentication, cookie management, and many more features.

1. http://curl.haxx.se/docs/manpage.html

The project has the benefit of being relatively small and straightforward, yet ripe for a number of the techniques from the book, in no small part due to its use of the network and, more specifically, the Apache HttpClient² library. The repository for this project can be found on GitHub at https://github.com/srvance/QualityCode14 as a series of micro-commits detailing the evolution of the software, missteps and all.

2. http://hc.apache.org/httpcomponents-client-ga/index.html

WebRetriever supports the following features, in which command line options refer to the corresponding option in the curl documentation.

• Takes options followed by one or more URLs.

• Retrieves content from URLs and writes content to the terminal unless options say otherwise.

• Supports only HTTP, defaulting to GET.

• Assumes HTTP if not specified.

• Supports -O to write the file to the same local name.

curl applies this option to the next URI. You need to put it before every URI if there are multiples you want handled this way.

curl happily overwrites files if the file exists, including if there are multiple files with the same name in a single invocation.

curl complains if there is no explicit file name, as in the default index for a site.

I have omitted some practices from this project that I would normally include and endorse. I did not set up static checkers in the Maven build and only relied on the default feedback from my IDE for style and error checking. Ordinarily, I would integrate either Checkstyle, PMD, and FindBugs (all three) or Sonar into the build and configure them for immediate feedback in the IDE. I would normally also use code coverage tools to provide feedback on the thoroughness of my testing. The focus on techniques leads me to omit that here. Finally, I have skipped writing Javadoc for the production code in the interests of brevity and keeping focus on techniques.