Here’s a brief overview of TDD:
- Write a test that fails (it fails because code that it tests is not written yet)
- Write just enough code so that the test passes
- Re-factor the code
- 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.