Test Driven Development
On Thursday I attended the PNSQC Summer Workshop on Test-driven Development. The presenter was Ward Cunningham. I picked this session to attend because Ward was presenting and I’d heard many great things about him. (For example, a few days before the workshop I attended an MS internal talk on test driven development presented by Alan Shalloway where he mentioned something to the effect that in the areas that he teaches Ward Cunningham is the master. Interestingly enough, Alan was in attendance at this workshop.)
Ward started off talking a little about extreme programming to give us context for how the day would proceed. He didn’t have any rigid agenda, just an idea of the main things we wanted to accomplish and a general approach of how to do it.
The first activity we did was to install the software that we would be using throughout the day. I already had Java installed, per the pre-workshop instructions, but there were some other things that were needed: WinZip, JUnit, FIT, and (optionally) Eclipse. The instructions that Ward gave us for installing the various tools included a verification that would tell us that we had successfully accomplished the task. This was the first time that I’d seen that done. Since everything was Java-based and I’m not a Java expert (in fact, I’m a rank beginner) I did have some problems getting everything set up correctly. (I wasn’t the only one, either.) The biggest issue most folks had making things work correctly was correctly setting the “classpath” environment variable. Once I understood the concept and mechanics of that, everything worked pretty well.
After we had all the software installed, the rest of the morning was a “hands-on” session which consisted of working through an example of test-driven development. The program we were supposed to build was a temperature converter. We were encouraged to work in pairs but I ended up starting off by working alone. Since I am currently reading Kent Beck’s book on Test-Driven Development, I started off in a manner similar to the way that book encourages people to do by writing a test first:
public class TemperatureTest extends TestCase
{
public void testF2C()
{
Temperature t = new Temperature();
assertEquals(0,t.F2C(32),0.1);
}
}
And then doing the minimum necessary to make the test pass:
public class Temperature
{
public float F2C(int f)
{
return 0;
}
}
Implementing a program in this way felt strange, but good. Because the test that I had written decided ahead of time what my goal was, I didn’t feel compelled to think about the million things that I usually do when I start implementing a program without a goal. The real goal for the first iteration wasn’t to deliver the final version of the program, it was to set things up and make sure all the tools worked as expected. Because I could pass the test by just returning a hard-coded value (and that was all right to do) I could focus on the issues involved with structuring my program and test code and figuring out how JUnit works. Two more iterations later, I had the final program done.
The insight that I got from doing this exercise was that, when doing test-driven development, the tests are more than just tests, they also are a mechanism for requirements and design. The methodology also controls your scope of concern to the goal of just the iteration you are working on which, for me, gave me a focus that let me get the work done in a more efficient manner than usual.
In the afternoon, we were introduced to FIT (Framework for Integrated Tests), Ward’s framework for acceptance tests. I was interested in this because someone on the Agile Testing group had posted pointers to FIT a while ago and I took a quick look there but didn’t really “get it.” After taking a quick look I didn’t go back. I was curious if I would get more out of it from the “hands-on” experience in the workshop.
FIT is designed for customer driven acceptance tests (as opposed to developer driving unit tests – the target of JUnit). FIT is composed of a driver, fixtures, and HTML data files. Fixtures are modules that know how to interpret the data that lives in their corresponding HTML files. This ends up being a powerful separation because you can have developers implement the fixtures but the individual tests are data driven from the HTML files which can be created by non-developers.
Someone asked why the data files are written in HTML. Ward said that it’s because there are so many tools out there that let people create HTML. It turns out, though, that the only thing FIT looks for are the <TR> and <TD> tags so it’s conceivable to author your data in XML too. There are some other cool things that FIT allows because the data is specified in HTML. One is the fact that you can embed your documentation in the same file as the test data. The other is that FIT will process the input HTML file and produce an output HTML file that contains the results of each test in another column (it’s color-coded as well). I could imagine taking the output files and copying them to a web server to let people browse the latest test results. Pretty cool!
The first FIT task we were asked to do was to modify one of the example fixtures that comes with the FIT distribution. Alas, my meager Java skills didn’t allow me to complete this task but the folks that knew Java were able to do the assignment. The final task was to break the class into 3 teams – one to implement a date calculator, one to build a fixture to test it, and one to author test cases in HTML. I hung back and ended up in the third group. The result? In a half hour we were able to complete one development iteration and complete the first round of tests. Not all the tests passed but, some of them did. Considering the situation I found that pretty impressive.
A few words about Ward’s presentation style:
Ward is really low-key. There’s no real urgency to his presentations; he just matter-of-factly explains things. He does a great job of giving you the concepts and guiding you to understanding the topic.
I really enjoyed this workshop.
8:26:08 PM 
|
