Automated tests: why untested code is debt

Almost every team agrees, in theory, that automated testing is important. And almost every team, in practice, finds an excuse to leave them aside. "We don't have time now." "The project is simple." “We test manually.” These are phrases that precede, with impressive regularity, the moment when everything starts to break.

Automated testing is one of those subjects where the distance between speech and practice is enormous. And this distance has a cost, paid not all at once, but in increasing installments over the life of a product.

This text is about why tests are no longer optional and what really changes when a team takes them seriously. It's not a tutorial. It's an argument, the argument of someone who has seen, on both sides, what happens with and without tests.

What are automated tests, really

Automated tests are programs that automatically check whether your software does what it is supposed to do. Instead of a person clicking and manually checking each change, a test suite performs this check in seconds, as many times as necessary.

But reducing testing to "checking that it works" is missing the point. Automated testing is, first and foremost, a safety net. They capture knowledge about how the system should behave and alert when a change breaks that behavior.

This network completely changes the team’s relationship with the code itself. Without it, every change is a gamble. With it, every change is a verifiable hypothesis.

Why this became non-negotiable

Software grows and changes all the time. Features are added, bugs are fixed, code is reorganized. Each of these changes carries the risk of breaking something that previously worked.

In a small system, you can test everything by hand. In a real system, which grows month by month, this becomes impossible. No one can click through all the flows with every change. The result of trying is tiredness, slowness and bugs that escape anyway.

Automated testing is the answer to this scale problem. They allow software to grow without verification becoming a human bottleneck. That's why they stopped being refinements of mature teams and became a basic condition for building something that lasts.

The thesis: Testing is about guts, not bugs

Here is my position, and it may surprise you. The greatest value of automated testing is not finding bugs. It's giving courage to change the code.

Think about the team without tests. Every change in a sensitive part of the system is accompanied by fear. "Will this break something else?" This fear paralyzes. It leads the team to avoid improvements, to leave bad code as it is, to not change what works out of pure fear. The product rots due to justified cowardice.

Now think about the team with good tests. The same change is accompanied by confidence. If something breaks, the tests let you know right away. The team can refactor, improve, evolve without fear. This freedom is the true gift of testing. They not only protect what exists, they free the team to build what comes next.

The types of testing and when to use each one

Not every test is the same, and understanding the differences prevents wasted effort.

Unit tests check small, isolated pieces of code. They are fast, cheap and should be the basis. They catch specific errors and provide almost instantaneous feedback.

Integration tests check whether different parts work well together. They are slower, but they catch problems that the unity ones don't see, the faults that live in the junctions.

End-to-end testing simulates real-world usage, from start to finish. They are the slowest and most fragile, but the closest to the user experience. They should be used sparingly, in the most critical flows.

The wisdom is in the balance: lots of fast tests at the bottom, few slow tests at the top. Inverting this proportion is a classic mistake that generates slow and unstable suites that the team learns to ignore.

An applicable example

Imagine a system that calculates social benefits for a public program. The rules are complex and change according to legislation. A calculation error could mean a citizen receiving the wrong amount, either more or less.

Without testing, every change to the rules is a huge risk. No one is sure that changing one rule didn't break another. The team is held hostage by fear, and mistakes end up reaching the citizen.

With automated tests covering calculation rules, every change is checked against dozens of known scenarios in seconds. If a change breaks a case, the team knows before publishing. Reliability no longer depends on someone's memory and is now guaranteed by the system. In something that affects people's lives, this difference is not technical, it is ethical.

The traps that invalidate the effort

The first pitfall is testing by number, not value. Teams that chase a coverage percentage as a goal end up writing useless tests to inflate the metric. High coverage of bad tests is false security.

The second is the slow and unstable suite. When tests take too long or fail randomly, the team loses trust in them and starts ignoring them. A skipped test doesn't protect anyone. Maintenance of the suite itself is ongoing work.

The third is to treat testing as a separate task, done later. Tests work best when they are part of development, not when they become an additional step that is always left until the end and never happens.

Code without testing is debt accumulating interest

In the end, the choice is not between testing or not testing. It's between paying now or paying later, with interest. Untested code is technical debt that silently grows until it collects its invoice at the worst possible time.

Teams that invest in testing are not slower, they are braver. They move with the confidence of someone with a safety net underneath. And this trust, multiplied by months and years of development, is what separates products that evolve from products that rust.

Testing is not about distrusting your code. It’s about respecting the future of those who will maintain it, including yourself.

If your team delivers software afraid of changing what already exists, perhaps the problem is not a lack of talent, but a lack of network. It's worth talking about. I have other blog articles about software quality, best practices, and engineering that delve into how to build that trust.