Testing, Unit Tests, TDD (Test Driven Development) are one of the first thing that we learn when we are in university and study computer science. A part of us might be lucky enough to have a specific course for TDD.
Code is written by people for machines that needs to resolve problems. People do mistakes and this is why it is so important to test our code. I didn’t have the opportunity to see until now a working application, without bug or issues from the beginning.
I would say that a complex application that is not covered by unit tests and without a testing process will end up in the trash. At the beginning of each project there is a classical discussion related to unit tests and code coverage.
- Do we need unit tests?
- Yes.
- What is the code coverage target?
- 80%, 60%, 20%, 100%....
It is pretty clear that we need unit test. An engineer needs to be able to test his code and check if what we develop is working as expect or not. The response for the first question is pretty clear. But when we jump to the next question – the discussions can take hours and hours.
The development team will try to push the value as high as possible. In contrast, management might push back. Constraints like time, budget, complexity or quality level might impact the decision.
In situations like this, both parts might have good arguments to sustain their point of view. We are in a gray zone, where people can easily fall in a defense mode. I was very often in situations like this and unfortunately, managers will win. They are the one that takes the final decision.
What we shall do in this situations?
The first thing that we need to do is to map all the risks that might appear if there are no tests or if the code coverage is too low. Once we done this, we need to stay with all the team and identify how this cases could be mitigated.
Mitigation for this kind of problem could be strange, but acceptable at project level. Solution like increase the number of testers, bugs will be solved in production or accept quality level to go down are strange solutions for technical people, but this can be acceptable at project level.
The most important thing is to create the risk map. In this way people that can take a decision can have the whole picture in front of them.
The second thing that we need to do is to try to identify what are the components where complexity is high and the risk to have issues are imminent. Once we identify them we can requests that at least these components to be covered by tests.
In this way we can ensure that the most complex part of the system will be testeed and the development team can write good and working code from the beginning.
The 3rd things that can be done is to try to focus to write tests that covers custom logic (business logic). It is more likely to have an issues on custom code that calculates the discount level than in the one that save the results in a database or make a remote request. Of course also at persistence level we might have a bug, but because this layer is used by many other components also, the risk of having issues there without detecting it at development level is much lower.
When the available time for writing tests is not as much as we want we shall focus to cover the most important stuff with tests. Cover the part of the systems where you know that you will have issue.
Conclusion
In the end, there is trade-off. Getting enough time to have 100% coverage is not often. Even with 100% code coverage, you will still have bugs in production.
Don’t forget that we write code that runs on machines, but needs to be read by people.
Is there such a thing as too much unit testing?
No, but taking into account time, scope and quality, the quantity of unit tests can be impacted, even if there is a direct impact on this triangle (time, scope, quality).
Code is written by people for machines that needs to resolve problems. People do mistakes and this is why it is so important to test our code. I didn’t have the opportunity to see until now a working application, without bug or issues from the beginning.
I would say that a complex application that is not covered by unit tests and without a testing process will end up in the trash. At the beginning of each project there is a classical discussion related to unit tests and code coverage.
- Do we need unit tests?
- Yes.
- What is the code coverage target?
- 80%, 60%, 20%, 100%....
It is pretty clear that we need unit test. An engineer needs to be able to test his code and check if what we develop is working as expect or not. The response for the first question is pretty clear. But when we jump to the next question – the discussions can take hours and hours.
The development team will try to push the value as high as possible. In contrast, management might push back. Constraints like time, budget, complexity or quality level might impact the decision.
In situations like this, both parts might have good arguments to sustain their point of view. We are in a gray zone, where people can easily fall in a defense mode. I was very often in situations like this and unfortunately, managers will win. They are the one that takes the final decision.
What we shall do in this situations?
The first thing that we need to do is to map all the risks that might appear if there are no tests or if the code coverage is too low. Once we done this, we need to stay with all the team and identify how this cases could be mitigated.
Mitigation for this kind of problem could be strange, but acceptable at project level. Solution like increase the number of testers, bugs will be solved in production or accept quality level to go down are strange solutions for technical people, but this can be acceptable at project level.
The most important thing is to create the risk map. In this way people that can take a decision can have the whole picture in front of them.
The second thing that we need to do is to try to identify what are the components where complexity is high and the risk to have issues are imminent. Once we identify them we can requests that at least these components to be covered by tests.
In this way we can ensure that the most complex part of the system will be testeed and the development team can write good and working code from the beginning.
The 3rd things that can be done is to try to focus to write tests that covers custom logic (business logic). It is more likely to have an issues on custom code that calculates the discount level than in the one that save the results in a database or make a remote request. Of course also at persistence level we might have a bug, but because this layer is used by many other components also, the risk of having issues there without detecting it at development level is much lower.
When the available time for writing tests is not as much as we want we shall focus to cover the most important stuff with tests. Cover the part of the systems where you know that you will have issue.
Conclusion
In the end, there is trade-off. Getting enough time to have 100% coverage is not often. Even with 100% code coverage, you will still have bugs in production.
Don’t forget that we write code that runs on machines, but needs to be read by people.
Is there such a thing as too much unit testing?
No, but taking into account time, scope and quality, the quantity of unit tests can be impacted, even if there is a direct impact on this triangle (time, scope, quality).
Comments
Post a Comment