Ed Burns's Blog

Extreme Programming Archives

All Hail TDD!

Way back in October 2002, I had the enviable position of ramping up the development effort for the Sun RI for JavaServer Faces. At that time, Test Driven Development (TDD) was just starting to catch on, and I used my position as team leader to mandate (HA!) that we would use TDD on the project. I realized that for any mandate to succeed, it must be easy to implement, so the team and I invested in building the infrastructure iteratively growing our test codebase. I can't tell you how many times that investment has paid off, but I'll tell you one time: right now.

While implementing Adam Winer's proposal for fixing the State Saving Window Id problem, I came across a corner case not covered explicitly in the proposal. Basically, the proposal re-allocated some responsibilities and neglected to re-allocate this one corner case, which happened to be caught in an HTMLUnit test, written by Craig, I think. Unfortunately, the net effect of this neglect was to throw the webapp into an infinite loop. It was very easy to re-produce: just visit the prefix mapped webapp and include only the servlet-mapping with no trailing slash and no viewId. Thanks to the unit test, I quickly found and fixed the problem, without introducing the bug into the code.

Welcome to the JavaServer (TM) Faces Implementation Project!

Hello, and welcome to my first blog on java.net. In spite of all the hype about blogging lately, I was still hesitant to jump into the blogging universe until I had something to say, and today I do: Welcome!

People have been requesting that Sun release the source code of its implementation of JavaServer(TM) Faces Technology for several years, and Sun's answer has been that doing so is under review. I won't go into the reasons for the length of the review process, but I'm happy to announce that it's finally complete. We have created an open development project on java.net to host the continuing development of Sun's JavaServer Faces implementation. All previously internal development will be done in this project; there is no private source tree that we really use. In other words, this project is not just for show. Please read the FAQ for answers to such pressing questions as "how do I get and build the source".

You'll note that I didn't use the term "open source", but rather, "open development". We're doing so out of respect for the rigorous definition of the term supplied by the Open Source Definition (OSD). I'm not a lawyer, and I can't tell you where the Java Research License, which we're using for our project, stands with respect to the OSD. I'll leave that to someone who doesn't write code!

In any case, as with any open development project, there are many levels of participation. You can file bugs so we know about them and can get the fixes to you as quickly as possible. You could simply grab our regular builds to check if your pet bug has been fixed. You can browse the source code to get an explanation of the behavior you're wondering about. You can, also (my favorite) build the code yourself and run it in a debugger for the ultimate in development transparency.

Presently we are only accepting Observer role members into the project, but we plan to open the project up to committers on a case by case basis once trust is established that our development processes will be followed.

So what are these processes? We'll have more detail in the FAQ but here's the idea. All the code in the javaserverfaces was developed using Test Driven Development. Each checkin must include either a new test, or a modification to an existing test to prove that the new code works as expected. Before checkin, each developer's workspace must successfully execute all automated tests, as well as have code review and approval from another developer. We employ the usual suspects to make this happen: ant, junit, cactus, and htmlunit. Heavyweight? Perhaps, but when you're testing resources are so taxed that they can't spend as much time as you'd like with your project, these measures are well warranted. I feel that our commitment to code review and test driven development has contributed significantly to the quality of the project, and helped to reduce the bug introduction rate.

To wrap it up, I'd like to share what we hope to gain from doing open development on javaserverfaces. This project aims to:

• be the most complete implementation of the specification.

• have a fast turn-around time for getting bug fixes into the hands of users.

• build a community of developers who are committed to increasing the quality of Sun's JavaServer Faces implementation.

• demonstrate uncompromising commitment to test-first development and code review for all code coming into the project.

This work is licensed under a Creative Commons License.