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 prefer to call "frantic code testing", which is something that needs to be avoided.
It is no secret that I am not a fan of paranoid unit testing. There are examples out there where people have more code in their tests than in the actual code base. You might think that unit testing helps you avoid technical problems, but the fact is that unit testing is more about getting a psychological effect rather than a technical one, it's a way to make you feel better about yourself - yes, I said it.
I am not against testing, I do vigorous testing myself during development, but I mostly prefer manual testing. During development every functionality is tested each time a minor change is made. 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 is correct, all the time. At the same time you try to break the software, do things that you're not supposed to do. 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. It is especially useful if you get into the habit of feeding the system the wrong kind of data. It is a method that requires patience and experience, but it is very effective. And no, it's not more time consuming that writing test, it's a more direct and natural part of the development process.
Unit testing, and other forms of test written in code, also help, especially related to old software, software that has been running for years and that is working perfectly, but you now suddenly need to add something that might effect other parts of the system, and you can hardly remember anything about what does what and why.
I do also implement automated testing and automated monitoring, especially on critical parts of a system, but only when it truly makes sense, and not as a rule carved in stone.
But again, as with the object oriented paradigm, the industry has become frantic about testing. And it is seriously really tiresome how all this "best practice" keeps being taken to the extreme. I have witnessed how the issue of code testing makes some people feel superior, and how it is being used to look down upon someone if they 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!?
That was a quote from someone (not naming any names) who has made it his mission in life to make sure that everyone else knows just how cool he is with his testing practices.
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.
When you get tied up in developing software for testing, and in design patterns and best practice, all your enthusiasm is lost and you lose 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.
You should never aim for a 100% test coverage, if you do that then you're doing testing wrong! 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. Unit testing can help some people here because if it is very difficult to write a test, perhaps the software is too complex. 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.
The parts of the code you truly feel insecure about is not the code that needs the best test coverage, it's the part of code that needs refactoring.
In any case, don't feel bad about yourself if you're not writing any code tests. The value of writing code tests is highly exaggerated.
Update 2021-04-01: I just want to comment on a few emails and comments I have gotten regarding this article.
I have been in the industry for 34 years (as of writing) and I am not talking about toy software or software that you only work on for a short time.
I have developed huge applications as well as minor ones, both as single developer and in cooperation with others. I have software that has been running at clients for more than 13 years with a huge customer base and tons of daily activity, still doing great.
A pattern emerged very early in my experience that coincides very well with the Linux kernel model of development.
By not focusing too much on patterns or "best practice" carved in stone, you are actually able to focus on the problems the software is supposed to solve. This doesn't mean that you should not care, or build crap that other developers would consider a nightmare to deal with, but you need to be practical. This is based upon pragmatic experience, not upon what other people (mainly the majority, or actually always the majority for some reason) are shouting loud about.
Whatever the majority is doing, and whatever people seem to be frantic about, is usually the wrong way to do things. I believe it is because people who tend to become religious about such matters are often very insecure and emotional, as soon as they see someone going against the current, 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 "sheeplings".
Oh, and by the way, yes I am serious.