TDD avoidance – Top 10 reasons

I’m sad to see we somehow got way too far from agile coding, best practices and quality. It seems that TDD has its life cycle curve inside our organization (who knows, maybe we can generalize further). At the beginning everyone is excited about the new way of working. They seem to be adapting things, trying out TDD, mocking and the other technologies. After a while, however, people feel test driving feature development is a waste of time. So they stop writing test cases and get back to their old way of working. At the end, the organization is left with very few people committed to TDD.

And this is the strange part. Quality drops, because nobody cares about it, but when it gets noticeable everybody cries around. And that is the point when people start shouting louder: “This code is pretty much a mess, we’d rather rewrite the whole thing”. A friend of mine told me the other day “you cannot expect people to be writing test cases; they lack dedication”. (By the way, in this case I wouldn’t expect them to be complaining about quality… but anyway) And I guess this is the point here. Lack of dedication.

I tried to figure it out, so I started walking around in the landscape and ask people why they don’t write test cases. Here is my top ten answers I collected. Are you ready? Ok, here we go:

  1. I am so smart I can implement this without test driving it
  2. I don’t know how to write tests
  3. This is a really small change, no need for tests
  4. This cannot break anything
  5. I’m in a rush, no time for TDD
  6. I wanted to write tests, but I didn’t 🙂
  7. It’d be too hard to test this mess
  8. TDD’s not a silver bullet. With or without it, doesn’t matter
  9. I’m prototyping
  10. I’ll do the real work, then you can play around with your tests

The sad thing is that I didn’t make up any of these…

I’d like to emphasis this one: “I’m prototyping”. It seems to me that as soon as people get to know about prototyping they get an excuse not to do TDD. Tricky prototyping this is after all. People write a bunch of code, call it a prototype and -guess what- check it in! Ok, first they cross their fingers and say “I hope this works”. So we fall back to Hope Driven Development (thanks for the term, Marcell).

And finally, number ten. I really heard someone say that when I proposed we do test driven development. Some people don’t even consider writing tests real work.

Sadly enough, people who already had the OMG moment seem to forget about tests (I call OMG moment when someone discovers how useful TDD is. Usually it happens when they miss a bug, but their tests catch it for them). One idea we could come up with is a regular TDD group, with the committed ones (this would involve regular meet-ups where we could teach each other tricks, techniques and other stuff. Perhaps after a while everyone will be confident about their skills, so we get several TDD mentors). Maybe we can place them in different  teams so they can “infect” others with TDD (they can insist writing quality code at pairwork sessions). Maybe it helps, maybe not. Any comments welcome.

Author: tamasgyorfi

Senior software engineer, certified enterprise architect and certified Scrum master. Feel free to connect on Twitter: @tamasgyorfi

3 thoughts on “TDD avoidance – Top 10 reasons”

Leave a Reply to Moses Boening Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s