Intro
There are uncountable articles and guidelines (and many excellent software engineering books) explaining how to write unit tests, integration tests, E2E tests, and other kinds of tests & how important they are. Nevertheless, it caught my attention that sometimes writing tests is still seen as a “good to have” instead of “the right thing to do”.
I am a huge fan of tests, and I personally think they should not be optional, but rather fundamental for most PRs (or a series of PRs about a change) to get approved. So I decided to write this post to share my thoughts about this topic.
Deciding which kind of tests to write (unit, integration, E2E, etc…), and how they should be written, is a topic that deserves a post in itself, so I’m not gonna extend on this topic here — but if interested read a bit more about the test pyramid.
I also recommend you to explore the TDD (Test Driven Development) approach if you didn’t do it yet.
A few words about quality…
After some years engineering backend services, and working in different engineering roles, I’ve learned that the top 1 priority that every engineer should have, is generating, aiming & maintaining quality (of all kinds).
Why quality? Because despite our main work as engineers, might be to find simple solutions to problems (and potentially implement them), that’s not everything. Our solutions need to work as expected, and need to be easy to maintain & to extend.
A system is usually not a static thing that remains in its initial state forever. Eventually (or most probably, all the time) a system will need to be modified or extended. New features will come in, requirements will change, bugs will appear and will require to be solved quickly, etc…
So again, our system needs to be prepared to be modified/extended easily, and that can only be achieved with quality.
So, should you skip the task of writing proper tests when you are in a rush?
Please don’t do it, and the reason is simple, skipping tests is a decision that goes against quality.
Do you need more reasons to believe me?
If you are still not convinced enough, keep reading 🙂
I think the reason number 1 that leads an engineer to skip the task of writing tests, is the aim of delivering the solution “faster”.
At first glance, this might sound fine. After all, tests can be added later… Right?
Sounds nice, but IMO it’s not a good idea. If we skip important parts of the development process such as writing tests, we are creating something that despite it might work now (if we are lucky enough), it will not have the quality we should aim for, and it might not work tomorrow.
In a few days/weeks/months or even years, someone will probably need to modify that system, and if the tests are not good enough (or don’t even exist), whoever takes the task, will be afraid of breaking something else (or everything).
So let’s just put ourselves in the shoes of whoever that person is. How can that person know if the system will be fine after the change? Even one step back, how can that person understand how the system was “supposed” to behave?
Really hard right?
One more thing, please don’t say to yourself “tests can be added later”. Most of the times, that later moment never comes. As soon as you ship that solution, you’ll have new priorities on the table that will shift your focus to something else, and you’ll forget about those tests (or they will be considered tech debt). That’s why I usually don’t like the idea of keeping things for later. It can very quickly lead to things not being done or not done in the way they should.
Don’t put off until tomorrow what you can do today
Benjamin Franklin
So again: why? Why are tests so important?
In short: Because they are the best way of capturing bugs before they reach the production environment. They are also great at documenting how the system is expected to behave. And last but not least, they make the system easier to maintain and extend.
Of course here I’m talking about well designed tests. Don’t fall into the trap of just writing 1 or 2 tests to fulfill the test coverage requirement. Tests have to be good. Having an 80% test coverage doesn’t translate to “my system is well tested”. Test coverage is just a metric.
In short… IMO if you don’t write tests:
- You may reach the market quickly, but you’ll end up with a low quality system in your hands.
- All engineers introduce bugs. That’s a fact, and it’s inevitable. Without proper tests, these bugs will start accumulating, and as soon as you realize, you’ll end up with a mess in your hands.
- Buggy solutions will end up affecting the customer experience.
- Bugs might even harm your users or have a negative impact on their lives, depending on the type of software that you are engineering (imagine designing a software for an aircraft for example, or a banking system, or a medical system, etc…).
- A system without proper tests, is a system that eventually will become difficult to maintain.
- A system that is difficult to maintain, eventually will also become difficult to extend.
- If a system becomes really difficult to maintain & extend, you have a big problem. When that happens, often the best alternative is to throw the system to the trash and start a new one (specially for big systems). And unless it’s really necessary, we don’t want to do that right?
So, did I convince you now? Hope so 😀
Final Reflection
If an engineer favors time over testing (or any other topic related to quality), eventually that decision will lead to problems. I can guarantee that.
Tests are NOT a waste of time (even if you heard that somewhere). As engineers we should always aim for best practices, and writing good tests is one of the most important of them.
Note that this post is just related to tests, but quality should be pursued in all aspects (eg: security, design/architecture topics, infrastructure, etc…).
Again, as engineers, we should always try to come up with our best. That’s the only way we are going to leave the right path for following engineers coming after us. That’s the only way we will guarantee to ourselves that we are doing a good job.
I hope at this point I’ve been able to convince you 😄
Thanks for reading!
Disclaimer: This post represents just my thoughts and my personal opinion about this subject. I’m not talking on behalf of any company I work, or I’ve worked for, nor giving real examples from neither of them.
Leave a Reply