Testing is waste of time, I know that my code works

Even though there are literally hundreds of books and articles about Test Driven Development, there are still lots of people that are untouched by the power of testing.

There are severals reasons why you might not want to write tests:

1. It takes too much time.
2. It is not worth it.
3. I’m too lazy.
4. I don’t know how to do it.
5. I know my code works because I ran it once and it worked.
6. I’m a superhero, I don’t make any mistakes.

Unless your answer was 6. (in which case I envy you), you should continue reading.

Let’s start with simple example. Say you’re writing an email validation.

You might do that by using regular expressions, or just simply by hand, comparing every single character.

Now you want to verify that your code actually works. How do you do that? You start manually putting in different inputs and check if validation meets your requirements, so you end up trying stuff like

foo
foo@bar
[email protected]

What happens when you change/tweak the validation algorithm? You have to repeat all that process again, inputting every single value and checking the result. Wouldn’t it be nice to have the computer check this for you automatically?

By automating the whole testing process, you can test it again and again whenever you want. This does not just save you time in the future, but it also gives you more confidence, because every time you feel that you might broke something, you just run your tests and see what happens.

Now imagine you’re writing something more complicated, like XML parser.

You can’t possibly create a parser without testing it, the question is, how to do it? Generally, you would create sample XML document and then throw it on your parser and manually check the results. Then, after you see your parser does exactly what you wanted, you convince yourself that it is finished and it works.

The problem happens when you find a bug. Now you have to change your working code and check once again that it works. But we programmers are lazy people, so you only check you fixed the bug, but you almost never check all the other parts of the parser. What could possibly go wrong, you didn’t break anything, right?

How would this work flow change, if you were writing unit tests?

First of all, you were already testing your application, you just had to manually test every function by hand and check the result by hand. This might feel OK when you do it once, but when something goes wrong, you have to do it again and again, and no one wants to do the same thing repeatedly, especially when it is boring.

On the other hand, you could write an automated test for every function of your parser. In this example, you are already testing your application, so there isn’t much new. You just have to change the manual checking for assertions, which will do it for you automatically.

Huge difference comes, when you find a bug.

Without any automated tests, you have to manually check everything to be sure that you didn’t break anything by fixing the bug. This get insanely unpleasant after few bugs, so you stop checking other parts of your code and just focus on the bug. If you had already written automated tests for you application, the only thing to do is press one button to run all your tests and immediately see the results without doing virtually anything.

How do you fix a bug when you’re using tests?

First of all, you have to reproduce the bug. No matter what, you have to first assure that the bug exists, before you start fixing it. So what do you do? You write a test that reproduce the bug that you are fixing, BEFORE writing any line of fixing code.

If you can not reproduce it, then the problem is somewhere else, and without finding it this way with automated test, you would be fixing bug on the wrong place, thus probably breaking your application. When you write the test, you must run it to assure that it fails. If it doesn’t fail, then something is wrong and you are not reproducing it correctly.

When you fix the bug, you already have an automated test for it, so you will find out immediately if the bug appears again.

What happens when you find another bug along the way?

You do the same thing. Write an automated test that can replicate the bug. Even though you don’t have time to fix it right now and it is not vitally important. You still want to have a test that can reproduce it, so when you come back next day, you see exactly what you have to do.