The absence of unit tests may indicate a lack of maturity in engineering
The number of good practices left out in IT can be daunting … Last week, for example, I wrote about documentation, a process that, although laborious, contains many benefits for technology teams.
Taking time to think about it, I stopped remembering other things that should happen in the technology teams to ensure the quality of processes and products, but that doesn’t usually happen. One of them caught my attention: the recurrent practice of unit tests.
In theory, unit tests should be performed by developers as soon as a function is coded. But what is generally seen is that there is a reluctance to code these tests. After all, why would anyone want to create more code to test what has already been coded?
Well, it’s not difficult to understand why. At all times, we need to deliver new features, evolve flows, and improve the customer experience. And delivering on time, quickly, is no longer enough. Deliveries must increasingly have quality.
For this reason, it is impossible to deny the role of unit testing — which, in itself, guarantees the functioning of the code in its smallest fraction.
Unit tests are essential to test modules, methods, classes, features, among others, and ensure that that unit is performing according to what is expected of it.
In my view, unit testing, like any other automated test, is critical to ensure that a product or functionality will perform even after a change. The role of regressive testing is to bring that security to a team, especially in an environment where there is pressure for innovations to be put into production.
Suppose a development team has a routine to verify that the code is doing what it should do. In that case, that team is protected by a “security layer” that increases delivery confidence. This prevents a product from failing and generating rework.
Another advantage? Unit tests generally take seconds to test an entire application, even after several changes have been made. Not to mention that when compared to user interface tests (which must also exist, because they are equally important), they are much less expensive.
Therefore, when we decide to take unit testing seriously, the scenario we have is several isolated test routines that can be performed numerous times. This allows anomalies in the code to be quickly identified and prioritized for correction, especially those that arise after modifications and changes. It is like an elaborate alarm system that flashes every time something goes wrong. It seems convenient.
I’ll go even further. I don’t think unit testing is simply a process. It is part of a quality culture in which the developer and QA work together, without the widespread belief that these two roles are always at war.
In my point of view, unitary and regressive tests are essential components of agile. But why? Because without that, there is no progress. It is trying to code a feature here and breaking a code there that worked, and no one can quickly understand why.
In teams that value quality above all, it is clear that the unit tests are there to help in the evolution of the architecture, encourage refactoring and build products that do not leave the user in hand. So it can be confusing to understand why these tests are so often overlooked.
It is not uncommon to see development teams ignoring practice when deadlines tighten or preferring that QAs do unit tests. It is okay for the QA to do a unit test here or there, but when it comes to quality culture, the developer’s role is also to guarantee the quality of what he develops.
In other words: everyone is responsible for the quality, and the developer is no exception. However, there is still no maturity to build this mindset in practice. And, while unit tests are not being done more often, it is better to doubt that this maturity exists.
