Worshiped by a large part of the developer community, unit testing (or unit testing, depending on the literature) has vast material explaining the most diverse concepts, often accompanied by widely detailed examples in all programming languages.
Some frameworks include several tools for creating and executing unit tests. And for those who are deprived of these facilitators, there are libraries that will readily meet the most diverse needs.
However, whenever this subject arises in developer groups, a question is raised: "How to implement unit tests in routines with high levels of complexity and serious organization problems?"
This question haunts even the most experienced developer, an expert in the code under his responsibility.
Well, the first time I heard about unit testing, I also considered it to be the solution to the development problems we had in our applications.
It was enough to create a class with a few methods validating a function or routine, where the result of each interaction would serve as a starting point to fine-tune the routine even further until eliminating (or reducing) any errors found.
Armed with the concepts and some examples I found, I set out to create my first unit test. I took advantage of the demand for a project in C# and developed the function and the test responsible for validating the newly created routine.
I confess to having been quite excited because I believed I had found a way to prevent a routine from breaking whenever a developer "passed" that way.
I found it. The problem was validating every bit of the "Spaghetti Code" that was in front of me. Methods with three hundred, sometimes even a thousand lines of code made the unit testing approach an almost impossible task to perform.
This finding took away much of the motivation for creating unit tests. But I understood (through osmosis, I admit... lol) the real importance of SOLID's Single Responsibility Principle:
"A class should have only one responsibility and there should only be one reason to modify it".
Good development practices preach the creation of tests before routines.
However, the application or not of this practice comes up against several obstacles and the biggest one, in my opinion, is the lack of a long-term vision.
This "myopia", so to speak, is a direct consequence of the scenario in which most technology companies are inserted, where there is a lot of competition for good products/services and deadlines are getting shorter.
Add legacy code to this scenario and we have the perfect formula for systems full of bugs and poorly designed interfaces.
However, all is not lost and unit tests are not the only way to validate a system or application. Other tests are performed in the various stages that involve the development of applications, from integration tests to black box tests where the system is validated by an expert.
Unit tests are great because they can be automated, saving time, but they should never be the only tool for finding bugs in a system.
A team aligned on delivery and with good knowledge of the scope of the project is worth more than a thousand unit tests.
See you soon. 😎
Top comments (0)