Test Driven Documentation

Esendex fully embraces the idea of test-driven development (TDD), something I was introduced to during my time at Fujitsu-Siemens Computers.
Microsoft have just released a new MSDN site called the Tester Center Home. Whilst I’m sure its got some useful information on it, the matter-of-fact MSDN style doesn’t invite me to delve into it to find helpful hints and tips on TDD, personally speaking.

It was while I was working for FSC that my manager decided to implement TDD and it was interesting watching the reactions of the development team.
I always remember one member’s reaction during one of several in-house courses they organised for us. He was used to working alone, delivering the goods in the time it took him, after several attempts at hacking at it in his own style.
In the course, we were discussing an example of a method to check the validation of credit card numbers. He was asking how you could possibly catch every permutation a user could enter into your application. You could tell by the slightly panicked look on his face that his expectations of TDD at that point were that you would be spending far more time writing larger tests than the actual method itself.
The trick is to just write enough tests to prove your method does what it says on the tin, and a few to prove that it catches the obvious things you expect to go wrong.
I’ve already learnt a lot from the other members of the development team here at Esendex on efficient ways of embracing TDD without it ever feeling a burden. And for the unexpected things that can crop up? The agile approaches to software development means we simply improve our tests as we find those rare cases brought up by following up support calls raised by customers. It means our tests are refreshed as often as our code base is as improvements and new features are completed.
You can argue the benefits of extreme programming, agile methodologies etc., but even if you’re coding on your own, TDD is a necessity as far as I’m concerned.