This post originated from an RSS feed registered with Agile Buzz by Jared Richardson. Original Post: Defect Driven Test Creation Feed Title: Jared's Weblog Feed URL: http://www.jaredrichardson.net/blog/index.rss Feed Description: Jared's weblog. The web site was created after the launch of the book "Ship It!" and discusses issues from Continuous Integration to web hosting providers. Latest Agile Buzz Posts Latest Agile Buzz Posts by Jared Richardson Latest Posts From Jared's Weblog

Defect Driven Testing is a great way to start accumulating testing coverage on a product that's already in the field. It's a pretty simple idea that lots of people are already using under different names.

The steps are simple.

1. Find a bug (also called a defect) in your product. Okay, I know this never happens to ~you~, but other people in your shop can use this. ;)
2. Write an automated test that exposes the bug. This test should fail with a message that points out the defect.
3. Take the test that fails and then work on your code until the test no longer fails. You know the code is fixed when the test stops failing. If the test doesn't fail anymore but the bug isn't completely fixed, fix the test you have already or add another one. This step is a lot like Test Driven Development.
4. Add the test to your Continuous Integration system so that it will be run every time the code changes. This will keep the defect from sneaking back into the product. When the defect does show up, laugh loudly and stomp it out again.

That's it. It's pretty simple stuff but very effective. What are the key points here?

First, write the tests for the areas of the code that need tests. Whether this code is under active development or is just intricate, you'll be adding tests directly on top of the code with known issues. It's possible that other areas of your code need automated tests more, but you can address those areas when you're actually fixing bugs in those areas.

Second, you'll be adding tests in familiar code areas. I say it's familiar because you've been tracking down bugs in the area. This means you don't have to go learn a package to write tests for it. You're already invovled. Take advantage of that.

Third, bugs generally come back to haunt you. Many developers keep multiple copies of the code on their machines. When they fix a bug in one tree, they don't always get the fix into the other trees. Then they commit code in the other trees along with your pesky defect. Instant bug regression. You can "innoculate" your code against regressions by testing in a Continuous Integration system.

Also, when you add one test, be sure to play a little test Jazz. Variations on a theme. You'll often find more than one bug in an area.

Try out Defect Driven Testing the next time you have to track down a bug and squash it. You can build a very effective test suite in a short amount of time.

btw, related blog entries are Types of Tests, A Short JUnit Tutorial, and JUnit is not a Unit Testing framework. Sorry for the Java bias. I plan on adding more dotNet resources as time allows, but the ideas do apply.

Enjoy!

Jared