What is the right code coverage percentage?

There are great code coverage tools, which can tell the amount of code that is excercised through tests. So natural question that stems out is: “what is the right code coverage percentage one should target?”. Is it 100%, 80%, 50%…? Here are few points that one should consider before setting code coverage goals for the organization:

a. Simple Logic

An application would have lot of simple code like: mundane get methods, set methods… these methods doesn’t have any logic. There is value (but very less value) in writing tests to excercise these simple code. Writing tests to these code, will increase your code coverage, but it would add very less value.

b. Complex logic

Certain components in application will have complex business logic with lot of conditional logic (if… else…). To excercise one single condition in that component, one might have to write lot of mock objects, instantiate/load several dependencies. Despite doing all these things, excercising one single condition will not increase your overall code coverage percentage. But it will add lot of value to your application.

c. Dead Code

Any application which is taking production traffic for a while, will have dead code. Removing dead code from the application needs careful, focused effort. It’s technical debt that has to be repaid with proper effort. Dead code will also bring down your code coverage percentage.

d. XML, Property files, DB configurations

Application uses XML, property files, DB configurations. These also make up application code. All the industry leading coverage tools doesn’t instrument XML, property files and DB configurations. It only instruments Java code. Thus you won’t be getting code coverage metrics on these artifacts.

So you might ask the original question: “What is the right code coverage percentage?”. Answer depends from organization to organization.

Here is what I follow:

1. 100% code coverage on the critical components

2. 50% code coverage on non-critical components