Write Right Java Faster Using Test-Driven Development

The benefits of embracing TDD

Jul. 31, 2006 05:15 AM

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

About John Evans
John Evans is the founder and president of JPEvans, Inc. (www.jpevans.com), a small independent computer consulting company based in Northern Virginia just outside of Washington D.C. John has over 10 years of professional experience in software development. He has successfully developed and deployed large-scale software systems for several large multi-national corporations.

About Richard Cariens
Richard Cariens is an independent software consultant in the Washington D.C. area (www.jpevans.com). He has over 10 years of experience testing, developing, designing, and architecting Internet technology and financial systems. Rich holds an MS in computer science from George Mason University in Fairfax, Virginia.