To Unit Test or Not to Unit Test?
To Unit Test or Not to Unit Test?
Get some insight on the importance of unit tests and well-organized software architecture.
Join the DZone community and get the full member experience.Join For Free
SignalFx is the only real-time cloud monitoring platform for infrastructure, microservices, and applications. The platform collects metrics and traces across every component in your cloud environment, replacing traditional point tools with a single integrated solution that works across the stack.
I am sure you have heard that leaving defects, bugs, or incomplete things in the code is translated as technical debt. Well, unit testing is the opposite — a technical investment. Let me tell you why.
I lot of people don’t like to do unit testing, thinking it's a waste of time and resources. They also ask what the point is because, if the business logic changes, you need to rewrite the unit tests. You can easily spot this because they start their argument by saying, “In my experience…” Usually, they just are not well-trained, and under the hood, they are saying, "I don’t know how can I properly do this." Read more about this phenomenon in How Developers Stop Learning: Rise of the Expert Beginner.
A lot of failing unit testing strategies (or lack of strategy) are actually a reflection of a problem on the software's base design. One of the biggest issues with not having good unit tests is the lack of consistency in the architecture of the code. When the architecture is neglected and several developers are working on it, all of them will create code the best way they know, and this will produce a project with a mixture of coding styles. A good software architect will set up a good skeleton or wireframe of the project and guidelines so all the code is consistent. Without that consistency, it is very difficult to create good unit tests.
The second biggest issue of not having good unit tests is duplicate business code, or code related to the same entity that is not organized properly. This is also the responsibility of the software architect. In enterprise software, I am sure you have heard about layered design, so you know that you must separate business code from presentation code and data code. Doing this helps a lot when doing unit testing, but often business code is not kept loosely coupled. Using objects that are very specific to the data or presentation layers causes a lot of problems for the business layer. For example, if you have a library to deal with retrieving data from a MongoDB database, none this has to be used in the business layers. From your data layer, you only return a POCO object to your business layer. I know it is more work, but quality work is more important than fast work. The same goes for the presentation layer; none of the objects needed to deal with the presentation, like a request and response objects on a web framework, should be passed or used in the business layer. In addition, only POCO objects should be used (for more about this subject, see this eBook).
The other thing that will help you properly group your code is following the guidelines of the Entity-Relationship model. Originally created for databases, it is very useful in software design. If you have an architecture like naming your classes after the entities (subjects), let’s say
“User” and the methods of what it does starting with a predicate,
“SendResetPasswordLink”; your code will be a lot more readable and organized, and it will help you spot duplicate code and eliminate it. Having well-organized code will save you a lot of time looking for things.
Those two points are crucial to have good unit testing. Now, any time business code is changed, it will be a lot more easy to create it, find it, and update it in the unit tests.
Unit testing, in the long run, is going to help you a lot to save time when the code starts to get complicated, when you need to change things, refactor code, and spot what code is affected by those changes, so you will not introduce hidden bugs on the production environment. It will save you a ton of work and time; if you do that same job manually, it will be very time-consuming — you need to see the big picture (nobody likes to work on weekends trying to find bugs in production after a new version deploy).
So, yes, it means that you need to work a lot more, since you need to ensure proper software architecture and dedicate resources to the unit tests, but you will have better software quality. The amount of time that will save you when the software becomes complicated and needs a lot of code refactoring is priceless.
Like any other practice, you can just not do it — and that's OK, you may not need it at all. Nobody is right or wrong for using unit testing or not. For me, it's like having a car without seatbelts. In my entire life of driving, I only needed them once, but it saved my life. It is nonsense to assume that since I never had an accident before or that they happened rarely, that I would want a car without seatbelts so I can save on the car costs.
In the long run, unit testing will save you a lot of time, resources, and headaches if properly done.
Published at DZone with permission of Alfredo Pinto . See the original article here.
Opinions expressed by DZone contributors are their own.