| By John Evans, Richard Cariens |
Article Rating: |
|
| July 31, 2006 05:15 AM EDT |
Reads: |
28,072 |
We decide to go with option 3, specifically Java regular expressions,
since there's some resistance to introducing a new and uncertified
framework at the client site. We start fleshing out the
FeedAutoDiscoverer by making sure it returns a list of strings. We know
that the regular expression must match <link> tags with a "type"
attribute of "application/rss+xml." We'll also want to extract the
"href" attribute from all matching tags, so we should be sure to wrap
the "href" attribute value in a capturing group. Our first version of
the FeedAutoDiscoverer looks
similar to Figure 4.
Lucky for us, the test passes!
After congratulating ourselves on our success, we realize that the
<link> attributes might appear in any order and with embedded new
lines. We decide to write a second test to handle this new scenario.
This test case switches the "type" and "href" attribute ordering and
adds a new line between them.
Sure enough, we find that our FeedAutoDiscoverer doesn't handle this scenario; the new test fails.
We open up the FeedAutoDiscoverer and tweak the regular expression so that it'll hopefully handle the new scenario:
- We add an OR operator to the original expression and switch the order of the "type" and "href" attributes in the new half;
- We add the DOTALL flag to the expression, which allows the '.' character to match new lines.
Now the FeedAutoDetector
looks like Figure 5
.
Running the test again results in failure, but it looks like the
regular expression may have worked since it's the contents of the list
that are wrong. Reviewing our changes shows us that we forgot to update
our capture group handling. We have two capture groups in the regular
expression and have to add the proper group contents depending on which
half of the regular expression worked, so we change our logic.
We find that the test now passes and we're ready to move on to adding
more tests for auto-discovering Atom link references, etc.
There's a lot more to do, but we're well on our way to delivering the
site "Feed Finder" service. If we wanted to, we could stop here with
auto-detection and start building out the downloader component and the
servlet, or we could extract an interface from the FeedAutoDiscoverer
and start work on fitting it into an IoC container like Spring.
Whatever we decide to do, we now have two tests that we can use to
sanity-check changes we make from this point forward that might impact
feed auto-discovery. If these tests continue to pass as we change the
system (and we should run our tests often), we'll become more confident
and comfortable with handling change.
(As an aside, at this point in real life, we discovered that there was actually a spec for ATOM-based feed auto-discovery at http://philringnalda.com/rfc/draft-ietf-atompub-autodiscovery-01.html.
So, we took each of the examples in the RFC and coded them up as unit
tests, and made sure that our FeedAutoDiscoverer successfully
discovered them.)
Conclusion
Test-driven development helped us in many ways on this project:
- It forced us to translate our ambiguous requirements into verifiable test criteria;
- The test criteria helped us focus on doing just what was
needed to pass the test, and thus hopefully satisfying the
requirements;
- We avoided the heavy front-loading of design documentation and focused on getting some working code.
While we'll ultimately write more code with this approach
we'll have fewer defects in the end product. Testing early will also
help us uncover requirements errors or changes that would be expensive
to address in the later stages of the project.
References
Subscribe to JAVA Developer's Journal Email News Alerts
Subscribe via RSS
