Skip to main content

Is there such a thing as too much unit testing?

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.

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).


  1. I think the questions are misleading. What is to have unit testing? Is it an obligation to have the code testable? Is it to have x% coverage (like half of project fully tested and the other not)? Is it related in any way to the possibility of future refactoring? How are the tests checked? Automatically when submitting or occasionally when someone decides they need to check?

    The first thing I realized about unit testing is that it forces you to write things a certain way. Having coverage may be nice, but also not representative. What I would push for is testable code, not tested code. And how do you "test" this? Just define a minimum requirement for one unit test and make every class that has any public methods or code properties have mandatory at least one.

    I've read once that intelligence seems to emerge naturally from attempts to keep as many options open. Without testable code you cannot have unit tests, with it, the choice remains yours.


Post a Comment

Popular posts from this blog

How to check in AngularJS if a service was register or not

There are cases when you need to check in a service or a controller was register in AngularJS.
For example a valid use case is when you have the same implementation running on multiple application. In this case, you may want to intercept the HTTP provider and add a custom step there. This step don’t needs to run on all the application, only in the one where the service exist and register.
A solution for this case would be to have a flag in the configuration that specify this. In the core you would have an IF that would check the value of this flag.
Another solution is to check if a specific service was register in AngularJS or not. If the service was register that you would execute your own logic.
To check if a service was register or not in AngularJS container you need to call the ‘has’ method of ‘inhector’. It will return TRUE if the service was register.
if ($injector.has('httpInterceptorService')) { $httpProvider.interceptors.push('httpInterceptorService&#…

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

Run native .NET application in Docker (.NET Framework 4.6.2)

The main scope of this post is to see how we can run a legacy application written in .NET Framework in Docker.

First of all, let’s define what is a legacy application in our context. By a legacy application we understand an application that runs .NET Framework 3.5 or higher in a production environment where we don’t have any more the people or documentation that would help us to understand what is happening behind the scene.
In this scenarios, you might want to migrate the current solution from a standard environment to Docker. There are many advantages for such a migration, like:

Continuous DeploymentTestingIsolationSecurity at container levelVersioning ControlEnvironment Standardization
Until now, we didn’t had the possibility to run a .NET application in Docker. With .NET Core, there was support for .NET Core in Docker, but migration from a full .NET framework to .NET Core can be costly and even impossible. Not only because of lack of features, but also because once you…