Introducing Test-First Development

Testers are often frustrated to receive a product for testing that turns out to be riddled with bugs. They want to know why some of the bugs couldn't have been caught during development. If only tests could be run before the code was handed off! I once learned the benefits of test-first development first hand. Here, I'll introduce a framework for testing and coding that I found to be very helpful, and give some pointers on getting developers on board with test-first development.

I led a small band of engineers in the middle of developing our company's one and only product. Every dollar the company spent brought it one step closer to insolvency. There was no leeway on the timeline, and our success as a company depended on putting a high-quality, easy-to-use product out the first time around. I was the application's architect and I managed the team. After several months of intense coding, we submitted the application to testing. What QA revealed astounded all of us: As they ran our application through a multitude of tests on every platform imaginable, the bugs seemed to grow from a small colony to a suffocating swarm.

As my engineers went to work attacking bugs, I set out to find a way to improve the process to ensure we created fewer bugs the next time around. A few more iterations like that first one, and we could very easily be looking at a failed product and a failed company. Although our development process included many quality techniques already, like strong requirements management, I searched the literature for more. After several days of searching, I felt like just revamping the second iteration to have fewer features and more time for bug fixing-then I stumbled across an article by Kent Beck and Erich Gamma called " Test Infected: Programmers Love Writing Tests ."

The Light Goes On
It seemed Beck and Gamma wrote the first paragraph for me: "Testing is not closely integrated with development. This prevents you from measuring the progress of development-you can't tell when something starts working or when something stops working." I read on, sensing an answer to our problem.

The authors introduced a simple opensource framework, called xUnit, that allows developers to write unit tests in the same language they use to develop the application. The authors also described a workflow: Write the test first, then write the code, and when the test passes you're finished with that piece of code. Furthermore, the developer arranges tests into suites, and the framework automatically runs the suite and gives the developer an immediate notification of each test success and failure. The developer uses these past tests as regression tests when adding new features and fixing bugs. Changes are not allowed to destabilize the product. Before a feature is considered finished, all of the regression tests written by all of the programmers must pass. I found myself looking at a simple framework, with a near-zero learning curve, that could be put to use immediately.

I sat there for several minutes staring at the screen. Two feelings swirled within me: excitement (Here's the answer!) and fear (of the daunting bug list). I also had some reservations…Was I just adding busywork to brilliant, competent, and overworked engineers? Since we were mid-project, could I expect any real, noticeable improvement? Would we be forced to leave out features for the next iteration to concentrate on bugs? Knowing that software only gets more complex the larger and more patched it becomes, I opted to introduce xUnit as a strategy to improve the quality of our future iterations. The