Retrospective
WebRetriever has reached a functional state with a couple of extra perks over its more mature predecessor curl, at least for the implemented features. It can default a scheme, and it automatically follows HTTP-based redirects. The latter could be seen as a liability if you want to use it to diagnose redirect behaviors, but for most content purposes it helps. As I left it, it works as developed if you do the Maven build and invoke it as a JAR.
Its functionality falls short of curl by a long shot, but as a demonstration of testing techniques that would get tedious. I have tested a few error conditions, but many remain.
From a software design perspective, it went through some fairly ugly and chaotic intermediate forms, but it is shaping up reasonably. At times, it tested the ability of IntelliJ to refactor unassisted.
I am not crazy about the arguments being handled in the URIs parameter of WebRetriever.retrieve(). The argument parsing—generously described as parsing—uses a simplistic approach that will not scale, but for a single option it suffices. Moving forward with other options, I would use something like the Apache Commons CLI library.4
4. http://commons.apache.org/proper/commons-cli/
It seems likely that a TargetSet might hold the list of Targets to be retrieved and possibly be the container for the global options, while options specific to an individual URI would live with the Target. Additionally, the error handling should be strengthened.
But as far as the main point of the exercise went, a demonstration of the use of testing techniques, it covered a lot of ground. First of all, I showed how to apply the techniques in a test-driven manner using a statically typed language. I used an understanding of what testable code looks like to craft tests that exploited the seams I was about to create and used my refactoring phase while the tests were green to position the code for better testability. Of the chapters on the testing implementation patterns, I used techniques from all but Chapter 13.