Friday, December 08, 2006

 

Test Driven Development (TDD) in a Nutshell

Here’s a brief overview of TDD:
  1. Write a test that fails (it fails because code that it tests is not written yet)
  2. Write just enough code so that the test passes
  3. Re-factor the code
  4. Repeat from step 2 until code is baked, then repeat from step 1.
Brief guidelines for good unit tests:
  • Write simple tests (if a test requires complex configuration and setup, it will eventually fall into disrepair).
  • Test one scenario at a time.
  • Tests are your specifications. Well written tests provide working specification of the code they test.
  • Name your tests accurately and consistently.
  • Use data that makes tests easy to read and understand.
  • Write tests that run quickly.
  • Make each test independent. You should be able to run them in any order.
The initial result of TDD is that you end up with a suite of tests to rely upon when you refactor your code. It gives you the courage to refactor freely and courageously, knowing that you have a ‘safety net’ that will tell you if you have broken existing functionality (providing you have sufficient test code coverage). But TDD also forces you to think like a consumer of your own code, with the positive side effect of producing cleaner, simpler designs.

The TDD sequence is often represented as follows (Note: Not the usual sequence for traffic lights!):
  • Red: Write a test (that fails)
  • Green: Write code to make test pass
  • Amber: Refactor until Green again, then repeat back at Red
Here are a few resources:

Books:
Test Driven Development: Kent Beck. Addison-Wesley.
Refactoring: Martin Fowler. Addison-Wesley.

Web:
http://www.agiledata.org/essays/tdd.html
Test-Driven Development in .NET by Peter Provost. An easy to understand introduction to TDD and unit testing.

# posted by Mitch Wheat @ 10:32 pm

0 Comments:

Post a Comment



<< Home
    

Powered by Blogger