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 Target
s 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.
18.118.138.195