Newsletter sign-up

View all newsletters

Enterprise Java Newsletter
Stay up to date on the latest tutorials and Java community news posted on JavaWorld

Test-first development with FitNesse

Learn how FitNesse can solve your quality problems

By Stephan Wiesner, JavaWorld.com, 02/20/06

During the last few years, I have worked in all roles of the testing process, using server-side JavaScript, Perl, PHP, Struts, Swing, and model-driven architectures. All projects differed, but they all had some commonalities: the deadlines ran late, and the projects had difficulties accomplishing what the customer really needed.

Every project had some kind of requirement, some were very detailed, some, only a few pages in length. Those requirements usually underwent three phases:

• They were written (either by the customer or by the contractor) and received some kind of official acceptance
• The testers tried to work with the requirements and found them more or less inadequate
• The project entered a phase of acceptance testing, and the customer suddenly remembered all kinds of things the software needed to do additionally/differently

The last phase led to changes, which led to missed deadlines, which put stress on the developers, which in turn led to more mistakes. The bug count started to rise fast, and the overall quality of the system declined. Sound familiar?

Let's consider what went wrong in the projects described above: The customer, developer, and tester did not work together; they passed the requirements on, but each role had different needs. In addition, the developers usually developed some kind of automated tests, and the testers tried to automate some tests as well. Usually, they couldn't coordinate the testing sufficiently, and many items were tested twice, while others (usually the hard parts), not at all. And the customer saw no tests. This article describes a way to solve these problems by combining requirements with automated tests.

Enter FitNesse

FitNesse is a wiki with some additional functions for triggering JUnit tests. If these tests are combined with requirements, they serve as concrete examples, thereby making the requirements even more clear. Furthermore, the test data is logically organized. The most important thing about using FitNesse, however, is the idea behind it, meaning that the requirements turn out to be written (partly) as tests, making them testable and, therefore, their fulfillment verifiable.

Using FitNesse, the development process could look like this: The requirements engineer writes the requirements in FitNesse (instead of Word). He tries to get the customer involved as much as possible, but that usually cannot be achievable on a daily basis. The tester peeks at the document repeatedly and asks difficult questions from day one. Because the tester thinks differently, he does not think, "What will the software do?" but "What might go wrong? How can I break it?" The developer thinks more like the requirements engineer; he wants to know, "What does the software have to do?"

The tester starts writing his tests early, when the requirements are not even done yet. And he writes them into the requirements. The tests become part of not only the requirements, but also the review/acceptance process for the requirements, which has some important advantages:

 

XpoLog Center Correlate application logs with server metrics - XpoLog

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.