Table of Contents
Do You Really Need to Test Your Code?
Why does everyone praise testing, yet most developers don’t write tests?
Testing is like The Emperor’s New Clothes: everyone talks about how great it is to avoid looking ignorant, but no one can actually see it. Why? Is there really no developer with their own judgment willing to question the value of testing in a software project?
While tests help ensure your code works correctly, they also add more code that needs to be maintained and that code can have bugs too. So it’s important to write them only when they’re truly necessary.
Why Don’t We Write Tests?
If you’ve worked as a programmer, you’ve probably noticed that most projects in the industry don’t use tests. Whether it’s frontend, backend, mobile apps, or game development. They’re just not common, and that’s a fact.
So if testing is supposedly all good and everyone speaks highly of it, why is it so rare to see it actually implemented in companies?
The short answer: because nobody wants to do it. Not the company, not the developers, not the clients.
Time is Money: Companies Don’t Prioritize Tests
In the business world, there’s one universal truth: time is money.
Companies care more about meeting deadlines and rolling out new features than ensuring every single line of code is perfectly tested. While testing is useful, it’s not seen as an immediate priority.
And why not? Because the benefits of testing pay off in the long run, while client demands need to be met now. If a client asks for a new feature “yesterday”, what do you think your manager will choose? Exactly. Forget the tests and start coding.
On top of that, testing isn’t something you can show off in a report or demo. Clients want to see screens, buttons, working features… They don’t care if there’s a test suite behind it. If everything seems to work fine, most clients would rather take the risk and move forward. After all, they’re the ones paying for the development.
Developers Don’t Like Writing Tests
Let’s be honest: writing tests isn’t exciting. It doesn’t give you the same thrill as building new features. There’s no instant gratification from seeing something new work for the first time. It’s tedious, repetitive, and sometimes outright frustrating. Especially when you spend hours fixing a failing test that refuses to cooperate.
To make things worse, writing good tests takes discipline and patience. Qualities that aren’t always easy to find in dev teams. Many programmers prefer to trust their instincts, thinking, “If I wrote it, it must be fine.” But even the best developers make mistakes. Now imagine how solid those tests will be when written by a burnt-out developer who’s been hating their job for years.
Finding skilled, motivated developers is already tough. And when companies don’t see testing as a priority (for all the reasons mentioned), it’s no surprise that no one even bothers trying to implement it.
Maintaining Tests Isn’t Free
Test code is still code, and all code needs maintenance.
Every time you change the production code, you need to update the tests. In an environment where requirements are constantly shifting, tests become an extra burden that nobody wants to deal with.
Over time, tests start breaking or becoming outdated. Eventually, teams stop paying attention to them or even delete them altogether.
For startups, testing is even less likely. When the main goal is to ship a minimum viable product (MVP) as fast as possible, no one wants to “waste time” writing tests. The priority is proving the idea works, not making the code flawless.
For startups, testing is a luxury they can’t afford. They’re usually surviving on investment rounds or early client revenue, and every second counts.
In the real world, projects don’t succeed because they have 100% test coverage. They succeed by delivering value to clients on time.
Companies don’t pay for tests; they pay for solutions.
If your obsession with testing is slowing down the team, causing frustration, and draining resources, then you’re part of the problem, not the solution.
Myths About Testing
I don’t think testing is always beneficial, and some of the claims made about it are more myths than truths. So let’s break down these overused mantras among developers.
If there are no tests, the code isn’t professional
This statement isn’t just false. It’s dangerous. Being professional means meeting the needs of the client or product efficiently while delivering quality software. And quality means functional code that’s clean enough to be maintained and extended comfortably.
Having tests isn’t inherently better than not having them. I have no problem saying it. In fact, there are plenty of successful and technically impressive projects where the focus isn’t on having an extensive test suite but on having an architecture that allows for rapid iteration and adaptability.
Some developers mistake having lots of tests for writing good code, but the truth is, you can have a massive test suite and still produce mediocre or poorly designed software.
Being a professional means knowing when tests are necessary and when they’re just a waste of time.
Tests guarantee bug-free code
The idea that tests ensure bug-free code is a half-truth.
Yes, the primary purpose of tests is to verify that the code works correctly. But what happens if the tests themselves are flawed?
At the end of the day, a test is just code that checks if other code does what it’s supposed to do. And since programmers write that code, there’s always a chance of introducing mistakes or missing edge cases.
Faulty tests are a real issue because they create a false sense of security. Why would I manually check the backend API I just wrote if my tests aren’t flagging any issues?
Tests can act as a safety net, but only if they’re well-written. And there’s no guarantee that we haven’t made mistakes in the tests themselves, so the risk of bugs will always exist.
Tests are an investment, not an expense
If you write tests for every single line of code without distinguishing between critical and non-critical parts of the system, you’re wasting time and resources.
Saying that tests are always an investment sounds great when arguing in favor of testing, but the reality is that code is constantly changing. What seems like a great investment in tests today could turn into technical debt tomorrow when those tests start breaking due to refactoring or changing requirements.
The goal isn’t to avoid tests but to use them wisely. Instead of aiming for full coverage, focus on the most critical parts of the system, where failures would have the biggest impact. Otherwise, you’ll end up with a constant maintenance cost that often outweighs the expected benefits.
Let’s be real: your tests aren’t adding as much value as you think. They just make for a nice code coverage badge on your repository.
These are some of the widely accepted statements about testing that are often used as fallacies. Especially by experienced developers when addressing junior programmers.
When to Write Tests?
Tests won’t solve all your problems, but they can be incredibly useful in certain scenarios.
This might seem like an anti-testing campaign, but I’ll admit. I also write tests in some cases.
Libraries or Code Packages
When developing a library for multiple projects or releasing it as open-source, writing tests is definitely worth it.
If your code is going to be used by others, or even in more than one project, he smartest thing to do is include tests that explicitly verify it works in all cases.
For example, in a React project, writing a test for every component might not be worthwhile. But if you’re building a component library like Material UI, you’ll want tests for the Button, Checkbox, Input, and so on.
Complex Features
If you’re developing a particularly complex feature, tests are not just recommended, they’re often necessary.
In programming, the best way to solve a big problem is to break it down into smaller tasks. These smaller tasks can often be handled with standalone functions that are easy to test with unit tests.
For instance, I recently developed a generic dependency injection system called Inversiland (similar to Angular’s or Nest’s DI, built on Inversify). At first, it seemed overwhelmingly complex, but by breaking down the functionality into smaller parts and writing tests for them, I was able to build and validate the system without too much hassle.
In that case, tests weren’t just useful, they were essential. There were too many moving parts to keep track of in my head. If you’re curious, check out the repository on GitHub for a solid example of a well-implemented testing strategy.
Critical System Implementations
Some parts of a system are far more critical than others.
Take an e-commerce site, for example. The user registration, login, and payment flow are the most sensitive areas. If you’re going to write tests for the application, these three functionalities should be the top priority to ensure that users can register, log in, and complete purchases without issues.
Writing tests for just these three features won’t take much effort, but it will provide significant security and stability. Smart work over unnecessary effort.
Business Logic / Domain Layer
If your application’s business logic (domain layer) is properly isolated, unit tests are a great fit.
Going back to the e-commerce example, let’s say we need to ensure that product prices are always displayed correctly after applying discounts or add-ons. In this case, we can write a test for the price calculation function.
By keeping this calculation logic in a separate function with proper test coverage, we ensure that prices display correctly throughout the app.
Outside of these scenarios, excessive testing can add more overhead than actual value. It’s all about using tests where they truly make a difference.
Alternatives to “Traditional” Testing
Testing is a tool we can use to strengthen parts of a project like the ones mentioned above, but it’s not always feasible. Whether because the application’s code is too coupled or because testing was not accounted for in project planning.
Luckily, there are other approaches that can help us catch as many errors as possible in different scenarios.
Code Reviews
Code reviews are a great way to manually validate that new errors are not being introduced into the application.
Most version control systems, like GitHub, allow you to assign reviewers to code changes. This way, before new code is merged, a colleague must approve it or suggest modifications.
Of course, code reviews aren’t foolproof, but they are widely used in professional environments. Having an extra pair of eyes on the code before it goes into production is always helpful.
Pair Programming
Another technique that helps prevent mistakes is pair programming, where two developers work on the same task together. One controls the keyboard, while the other provides instructions.
Similar to code reviews, four eyes see more than two, so what one developer might overlook, the other will likely catch.
I don’t think this technique is practical for an entire workday due to productivity concerns, but it’s highly effective for specific parts of development or debugging sessions when tracking down an elusive bug.
Error Monitoring
Companies that don’t focus on tests often allocate their resources to mitigating errors quickly when they occur.
It’s common to implement an error monitoring system in production using tools like Sentry, which alerts developers whenever an error occurs in the application.
These alerts provide useful information, such as the exact line where the error happened, the time, and the browser or device used.
All these techniques can be combined and serve as a solid alternative to traditional testing when necessary.
Conclusion: A Pragmatic Approach to Testing
Testing is neither a magic bullet nor a villain. It’s just another tool that should be used wisely. Its usefulness depends on the context, project goals, and available resources.
You don’t need tests to prove you’re a good programmer. What you need is the ability to determine when they are necessary and when they are not.
My advice is simple: don’t write tests just because “you have to”, and don’t obsess over perfect code coverage. Write tests when they genuinely add value: for critical features, complex calculations, or reusable code.
And if traditional testing isn’t an option, remember that there are other equally valid alternatives: code reviews, pair programming, and error tracking.
What matters is not following a dogma but focusing on delivering functional software. Because at the end of the day, no one cares how many tests you’ve written. What matters is the value you bring to your client and how productive you are for your company.
