Heard a nice short podcast from NetObjectives on impediments to TDD this morning. I had to register to get to it, but it doesn't cost anything.
They considered the problems associated with TDD adoption. One which struck me in particular is the problem of many tests breaking when a minor change has been made. This tends to push developers to 'temporarily' ignore tests so they can get their work done. Which often becomes more than temporary. I know I've built up a test maintenance burden this way.
They addressed this by defining a "good" unit test as follows:
- A unit test should fail always for a well understood reason.
- A unit test should never ever fail for any other reason.
- No other unit test should fail for that reason.
Well, I'm guilty.
Sometimes I get going on writing unit tests without being mindful of my 'well understood reason' just for the sake of hacking out tests. This is a nice formulation for me to keep in mind.
xUnit Test Patterns has a lot to say about this kind of thing too.
No comments:
Post a Comment