Typical arguments to avoid to write automated tests… and their counter arguments :)

As a test aficionado, I often have to deal with some people who are refractory to tests, with many stereotypes and preconceptions. Here is the top 8 (no priority order) of the refusals I encountered.

1. Write tests will cost me too much time

1. Of course it will take some time to write tests, but you have to consider this as an investment. You’ll gain time after, by not having bugs coming again and again.
2. When writing tests, you learn how the different parts works together, as a consequence, you’ll better know your system and you’ll be more efficient when debugging bugs and problems.

2. Code isn’t testable

1. cif your code isn’t testable, it is probably not re-usable neither nor easily configurable, you’ll have many more problems with this code. You’ll have to cut/split your code in smaller parts, use interfaces when possible, learn how to make some dependency injection.
2. BTW, I never saw any code that wasn’t testable at all, (well, maybe assembly code for very specific processors is difficult to test without hardware… but even in those case, tests can be done through test bench)

3. There are still bugs with tests

1. Yes, it is true, this is a direct correlation between code and bug, . Automated tests are probably more efficient to protect against regressions bugs than avoiding new bugs, but regressions are the nightmare of any developers and IT managers.
2. If you write tests during the development phase, you’ll surely find bugs as if you were doing manual tests but those bugs will be fixed permanently (once the test is written, bug is definitively buried).

4. Write testable code is too complicated

1. Yes, this is true, but writing bug-free code is even more complicated :)
2. Don’t be afraid, it is difficult for everybody, as it was difficult the first times you wrote code, but the more you’ll write tests and testable code, the more comfortable you’ll be in writing tests

5. Test code will enlarge the quantity of code to maintain which would lead to a higher maintenance cost

1. Well, according to my mailbox, everybody needs to enlarge his….Oh,… no, not this time, sorry…
2. This is right, more tests means more lines of code… but, there is a compensation, with a good test coverage, refactoring your code is easy and harmless, so you’ll be able to reduce the amount of code to maintain => win-win ?
3. Your base code will probably be a little bit biggest, but more modular and more isolated (which is a consequence of writing tests), so you’ll have less difficulties to replace/change/split your code base into smaller parts and then, reduce maintenance cost.

6. We don’t need tests, we just write some small patches

1. And the code you’re patching doesn’t have got any tests ? If you really only create some patch to existent code, this is the good time to start learning how to make some functional tests (or system tests), you’ll have to test a complete functionality from a higher level.
2. This is the good starting point to follow the boy scout rule : “Leave your code better than you found it.”. If the original code doesn’t have any tests, start to write some :).

7. I don’t need test, I make PR and code review

1. Code review (and Pull Request) is better than nothing of course, but its efficiency to detect bugs is too much related to the experience and implication of the peers, and you’ll have to follow some rules to make efficient PR (small PR, isolated modifications… many things you make naturally when doing tests 😇 )
2. Anyway, it won’t protect you against regressions, but tests will :-) .

8. We don’t know how to write tests !

1. This one is a good argument, but nothing is impossible ;) start reading good online resources about writing tests, start with the Way of Testivus from Alberto Savoia, this is a good start to understand the mood of testing.
2. So you don’t know how to write test, but maybe some of your colleagues already wrote automated tests ? Try to ask them the good way to do it (people who are writing automated test are often very happy to share their knowledge with other developers, don’t be afraid to ask them for help, you’ll be rewarded)

If you liked this article, clap your hands ;)

Reactions, comments, remarks welcome, feel free to comment/start discussions :)

Originally published at pythonic-stuff.blogspot.com on December 7, 2018.