Stop being frantic about code testing

Published on 2021-03-31. Modified on 2021-04-01.

Code testing is not only great, it is a MUST as you cannot develop software without testing your code. However, there is something which I like to call "frantic code testing", which is what I believe needs to be avoided.

There are examples out there where people have more code in their tests than in the actual code base, and they spend more time writing tests than writing code, they even think more about testing that coding. In such a case we're not really dealing with testing in the true sense of the word, rather we dealing with the psychological effect of "feeling good about yourself", because you have a high test coverage and you see a lot of "green lights". It's a way to make you feel better about yourself.

I am not against testing. I do several kinds of testing.

When I work in Go, I use Go's built-in support for unit testing. When I work in PHP I use simple homemade testing code because all the testing frameworks are simply too slow to be bothered (PHPUnit e.g. is horrible slow). It's so easy to code a simple testing suite in PHP yourself, you don't need a tool for that. If e.g. you're developing an API, you can just make a PHP script that runs cURL against you different endpoints and then check for a valid response - just as an example.

As a fundamental principle I only test code I truly worry about.

Also, I am old-school, so during development I do a lot of manual testing. The method I use is a rigorously usage of inserted breaks, where you halt the application at specific places during runtime and then check that the values and data are correct, all the time. At the same time you try to break the software on purpose, you do things that the user is not supposed to do. You always feed the system the wrong kind of input. It is a very effective way to discover bugs early during development, because it not only quickly becomes a natural part of the development process, it is also better related to the way the software is intended to work, if it is going to be used by people and not machines.

In my experience, unit testing is mostly relevant in relation to code refactoring, which is when you re-organize or re-structure your code to make it easier to add features or fix bugs.

Imagine you have some old software, software that has been running well for years and it is working perfectly, but now you suddenly need to change something in order to add a new feature, and you can hardly remember anything about what does what and why. Even if the code is well structured, you might make a mistake by assuming something about the code that is wrong. If you have unit tests in place, they will help you validate if the changes you make breaks something.

Automated testing and automated monitoring is also very useful, especially on critical parts of a system, but only when it truly makes sense, and not as a rule carved in stone.

Sadly, as with the so many other things in this industry, many people have become frantic about testing. It is seriously tiresome how all this "best practice" keeps being taken to the extreme. Some people feel superior because of their testing and they look down upon someone if that person haven't got a good test coverage.

Naturally your code already has comprehensive test coverage so I don't need to tell you that X is a bad idea right!?

In my humble opinion, and with all due respect, it's borderline stupid how much weight is being put on testing nowadays. So much so that it can actually have the opposite effect. Rather than focusing on the problems that the software is supposed to solve, people spend more time developing tests and getting the code to pass.

Unless you're developing mission critical software you're much better of concentrating on the programming and problem solving. Then release early and release often. Don't worry too much about software failure as it is bound to happen no matter what you do. Plan ahead instead. Have a solid strategy for how you deal with failure, when it happens. And stick to testing the most critical parts of the system, the code that you worry about. Never test code that is obviously correct - that's just a complete waste of time.

You should never aim for a 100% test coverage, if you do that then you're doing testing wrong, in my humble opinion.

Major parts of the software are obviously correct and requires absolutely no test coverage, don't waste your time on that part. Focus on the parts of the software that are complex, then before you begin writing any tests, consider if there are ways in which you can simplify the complexity. Perhaps you can divide the code into even smaller pieces, and perhaps you can delegate responsibility to other functions. However, some parts of the software needs to be complex and you simply cannot avoid it! And no amount of testing will do you any good! Not everything can or should be broken down into teeny tiny pieces. And don't even get me started on TDD being the driving force for the design of a program - a programmer should be focused on the data, not on the code!

When you get tied up in developing software for testing, and in design patterns and best practice, all your enthusiasm is lost and you loose precious energy that could have been spend creatively coming up with better and more efficient ways to deal with the problems you're facing.

When you're "in the zone" you can hardly stop thinking about ways to improve stuff and find new and better ways to do things. You might be in the shower or taking a walk and suddenly you get a bright idea and can hardly wait to try it out. All that is strangled to death when 90% of your time is spend worrying about writing tests, fulfilling the demands of the design patterns and "best practice" fanatics.

The value of writing code tests is highly exaggerated. The more critical a system is, the more justified unit testing and automated testing becomes.

Whatever the majority is doing, and whatever people seem to be most frantic about, is usually the wrong stuff. I believe it is because people who tend to become religious about such matters are often very insecure and emotional and as soon as they see someone going against what they themselves follow, they become afraid because this jeopardizes their own position in life. They stand where they stand, not because they themselves have been thinking deep and hard about the stuff they do, but simply because they are the "blind followers" of others.

Much of the so-called "best practice" is all about specific people making themselves feel important, selling books and being payed a lot of money to do talks.