Testing: Why Bother? - Introduction

I stumbled upon an interesting discussion this week in the testing-in-python mailing list, asking how to explain why testing is important to a "we do not write tests" audience. Because this is something I had to do a few times already, I thought about writing a blog post about it (actually, a series of posts...)

Testing? What do you mean by that?
Well, there's a lot of things that can be related as "testing" when talking about software development. There's TDD, Unit tests, Integration tests, having a QA engineer test your code, and more.
In these posts, I'm talking about justifying writing any kind of automated tests that can be run through a CI (Continuous Integration) system after each commit. It doesn't matter if they were originally written during practicing TDD, the important thing is making sure there's something that's always there to test nothing was broken after each little changeset in the code.

So, what's the deal? Why do I need to write tests?
Well, the advantages of testing your software are usually clear and aren't really debatable.
Every one will agree that when you write and run automated tests for your code, you become more confident that your code works, and when you run your tests after each change you make you can gain confidence that you didn't break anything.
The problem is, though these advantages are pretty much obvious and clear to anyone, the majority of developers do NOT write automated tests.

But, if testing is so awesome, why wouldn't everyone write tests?
Well, there are 2 kinds of anti-testing developers (that's how I'm going to refer to them from now on).

One type of anti-testers, are the kind that simply lack the education. Most programmers don't learn how to write tests as part as their formal education, and therefore when they start at their first software industry job, they usually don't write tests unless exposed to this subject as part of the company's training and mentoring. Because concepts like TDD and CI are relatively new, a lot of old-fashioned team leaders and R&D managers are not exposed to the importance of testing as well, and they don't demand this from new employees and don't include this in training them to the job.

These kind of anti-testing developers are the relatively easy kind. They did not already develop antagonism towards testing, and they may be easily persuaded by fellow pro-testing developers, teammates, managers or external preachers.

The other type of anti-testing developers, is the type that I'm targeting these blog posts towards. These are developers that are already exposed to the concepts, maybe even experimented with testing a little bit in the past, but claim to have some solid reasons why testing is a waste of time for them, and simply do not believe in it. There's usually a list of excuses they give to justify their hostility towards testing.

The list of excuses
In my experience as a pro-testing preaching developer, I've come across some various types of resistance. I've collected a list of common excuses for justifying the anti-testing approach:

• Writing tests takes too much time
• Writing tests is too hard
• It's QA's job, and they are going to test our code anyhow
• Running the tests takes forever, so we never run them anyhow
• We frequently refactor everything heavily, all the test code is going to break and be irrelevant anyhow
• We hire only extremely talented developers. We never have bugs
• Even if we'll write tests for everything, we're still going to have bugs
• It's hard to tell how the code behaves each time, so I can't write a test for it
• Writing tests is boooring!

In my next posts, I'll try to attend all of these excuses, and clarify why I think they are plain misconceptions.

Can you think of any more excuses? Please let me know in the comments.