Bootstrapping

A purely test-driven project starts with a test. However, creating the repo in GitHub creates a README.md if you want it to be able to clone it. This is a good opportunity to write the spec for the project, or at least the initial spec, so I wrote that first.

Next, I used Maven’s archetype generation to set up the structure of the project. I chose an archetype that generated a project for Java-executable JARs, which generated the main class and its test class. As discussed in Chapter 6, I started with the constructor. I did not have an immediate need for attributes, so as the full recipe for bootstrapping the constructor did not apply, I squeezed a simple default construction test [445f41f] between various project setup commits. Test-driving begins in earnest with [0c2d67e].

Notice that I start by testing the construction of an instance and the primary method of interest for the first feature. I do not test the main() method. Why is that?

Unless your class has significant static content, it can be almost impossible to test a main(). While you could invoke main() from a test method as a static method, it generally creates a nonstatic instance of its own class or another to do the work. The best approach keeps the main as thin as possible, thinking of it only as the top exception handling layer around the functionality of the program. The simpler it remains, the less you miss by not testing it. You will see the complexity of WebRetriever’s main() fluctuate a little over the course of the project, but it will eventually settle to a very simple form.