Writing tests is part of our daily business as developers? And thats good.
IMHO there are only two scenarios where it is okay to not have tests:
- The code is a "proof of concept" or any other kind of experiment and you dump the code after the experiment
- Your business does not need the code to work properly now and never
Skipping writing tests is usually regarded as part of the technical debt you accumulate in your codebase. But before you decide to skip writing tests you should have a full picture of what you miss.
Code Quality and Reliability
The elephant in the room is that tests improve the quality and reliability of your code. They ensure that your code meets the requirements and works in all required scenarios.
As you might know there are different types of tests (I cover them in another blog post in detail):
- Unit tests: they test a single unit (usually one class)
- Integration tests: they test a bigger part of your software (usually a couple of classes working together)
- Acceptance tests (sometimes called "end-to-end" tests): they test the whole software together
Now lets have a look at the relative cost of finding a bug at a certain point in time of your development cycle. Below is a diagram that shows the relative cost of finding and fixing a bug based on a study done by the National Institute of Standards and Technology (NIST) by analysing a lot of projects:
Skipping writing tests can cost you 2 to 6 times more time and money to find the bugs and fix them! There are studies that suggest an even higher ratio. So you can see this numbers more like a lower bound.
The time and money you safe by skipping writing tests you have to pay back manytimes. Sounds like a bad idea, right?
Code Management and Maintenance
Changing code is day-to-day business for a developer. That is what we get hired for. Have you ever had to work on legacy code someone else has written without tests? Trust me: code you have written 12 months ago is "someone elses" code. If you do your story refinements and you and your team thinks: "Nah, better not touch this!" or "OMG, we do not know how this works!" you know what I mean.
Refactoring Confidence
If your code has a good working test suite you can easily refactor the code without breaking tons of stuff. Even crazy refactorings like replacing your custom code with off-the-shelf libraries are easily done with propper tests in place.
If you want to use tools like Renovate Bot (and you absolutely should!) every PR or MR is a small refactoring that can break things!
Documentation
Tests also serve as examples and as documentation for the code. A couple of tests are more descriptive than a ton of written documentation. Written documenation is already outdated when you write it (or do you ALWAYS update the written documentation?). But the tests need to be always in sync with the code - otherwise the tests will fail.
Enhance Architecture
You have tests and every change forces you to update a lot of tests? Well then you feel another benefit of having tests! This may sound counterintuitive but this shows that your codebase is tightly coupled or has low cohesion and so every change ripples through a big part of your codebase.
When components (classes, modules, functions) within a system are highly interdependent on each other, they are said to be tightly coupled. A change in one component often forces changes in another, indicating a strong and often tangled relationship.
Cohesion refers to how focused and related the responsibilities of a single code unit are. Low cohesion means that a component tries to handle too many unrelated tasks or is responsible for more than one well-defined role. In other words, the internal parts of a module have little in common.
Stakeholder Confidence
Your product has a lot of stakeholders all with their distinct set of requirements you have to meet with the code you write.
Customers that always get new features in time that work and don't break older stuff they love will more likely be a customer for your company tomorrow.
If you get an audit (for example ISO/IEC 90003) it is much easier to pass the audit when you can show the auditor a couple of tests in your testsuite that show that you meet the required legal and compliance requirements (whatever that might be in your case).
Writing tests significantly enhances stakeholder confidence by building trust in the development team’s competence and professionalism. Stakeholders often have concerns about whether the team is capable of delivering a high-quality, reliable product that meets business needs. A disciplined testing strategy demonstrates the team's technical rigor and commitment to quality, showing that they anticipate potential issues and proactively address them. Well-written tests reflect the team’s expertise in ensuring functionality, reliability, and maintainability, reassuring stakeholders that the team can handle complexities and adapt to changes effectively. This trust fosters stronger collaboration and confidence in the team’s ability to deliver successful outcomes.
Summary
Testing is a critical part of software development. Aside from rare situations—like quick experimental prototypes that will never go into production—omitting tests generally leads to technical debt.
Tests ensure code quality, reliability, and maintainability. They identify bugs earlier, reducing costs since finding and fixing errors late in the cycle is far more expensive. A well-tested codebase also makes refactoring safer and encourages better architecture by highlighting problematic design elements like tight coupling or low cohesion.
Furthermore, tests serve as living documentation, increasing confidence for both developers and stakeholders. Overall, properly tested code fosters trust, adaptability, and compliance with external standards, ultimately benefiting both the development team and the business.
Comments
Post a Comment