The dark truth about software testing

4 min readJul 16, 2023

Why do we write tests? Who is behind this? What do they stand to gain?

A meeting of people in a dark room with a fireplace. Something sinister is happening, it must be about software testing. By Dall e

There exists a secretive organization known as the international society For Formidable Software (isFFS), composed of influential figures from the technology industry. Their primary goal is to maintain control of the software market by forcing endless wasted time on useless software testing. At the same time, they test properly ensuring that only their products dominate the industry.

The isFFS, through shell companies and covert financial transactions, invests heavily in the development and marketing of substandard testing tools. These tools are designed to provide superficial results, overlook critical issues, and fail to detect hidden vulnerabilities.

Avoid the conspiracy

The principles of testing

So fellow developer now that you know the truth, here is a guide you can follow to ensure you are not falling victim to the isFFS’s secret plan!

4 reasons why we write tests

It’s the easiest way to convince myself that my code will do what I want it to do
When writing tests, edge cases come naturally — and that helps in figuring out what can go wrong earlier in the process
Tests make it more tricky to accidentally break the behavior of the system
Tests act as documentation for everyone reading the code in the future. It’s a type of double bookkeeping

“The ratio of time spent reading vs. writing is well over 10:1. […]
Because this ratio is so high, we want the reading of code to be easy, even if it makes the writing harder”
- Uncle Bob

Do dos 🦤 and don't dos

There are a lot of reasons why we test but all of them are often met with the answer: but it takes time 🕓.

Let’s optimize our time then. The goal is to be efficient at testing

Do write the smallest amount of tests that make you feel confident that your application is doing things right
Do think ahead about the maintainance of your tests
Hint: If a test closely follows the business, there is a smaller chance that its maintenance costs will skyrocket with time
Do consider how much splitting of “units” is necessary for your use case see my previous story for inspiration
Don't focus on test coverage; it’s a useful indicator and it should remain a side-effect of testing — not a goal
Don’t treat test code as less important

Let’s get practical, shall we?

You are writing the backend of a cookbook application and you want to build the following feature:

The user of the cookbook wants to store new recipes.
The recipes need to have a title, and a description (ok maybe too simplistic).

You are a backend developer, you hear the requirements and you just can’t stop yourself from coding. Your hands are burning with enthusiasm and you are waiting for this magical moment when your IDE will auto-complete your code.

It’s so simple, I will add a controller, a service, and then a repository, and my feature is done. If only I wasn’t forced to write tests I would be done in 10 minutes 😡

Break the habit

As developers, we have been taught that we are only considered great if we know exactly the full solution as soon as we hear the problem.

Let’s try an experiment. You are still a backend developer and you still have the same feature to work with:

The user of the cookbook wants to store new recipes.
The recipes need to have a title, and a description.

What is the minimum amount of tests that can safely verify the behavior of the system?

Maybe something like that 🤔

The minimum set of tests to ensure the correct behavior

I have to stress that this is just the starting point — not an exhaustive set of tests that will verify the correct behavior of the system.

Back to defaults

Let’s shift things around: This time, imagine the tests you would write after the “code is ready”. So you already wrote a controller that passes over to a service then a repository and then a db. What will the tests look like if you write them now?

My best guess is that they will look something like this:

The takeaways 🥡

The point of view when approaching testing can dramatically change the nature of the tests. Having as a starting point the behavior of the system rather than the internal architecture of your applications tends to make tests easier to understand and more maintainable.

If you don’t convince yourself that software tests are inherently useful they will never become useful. It all depends on you.