Getting the balance of code coverage right for your tests is important. If you test too much – the level of effort required to implement the tests outweighs the return on investment. If you test too little – you leave your product at risk of too many undetected flaws at release.

There are some good rules of thumb to apply when deciding what level of coverage will work for you:

Determine the cost of failure. If the failure of your code might result in large financial penalties or risks to your customers – your testing needs to cover that area of code.

Determine the resources at your disposal. You need to be realistic about the work your team can do if your team isn’t big enough or lacks the experience to churn out tests quickly – consider reducing the level of coverage.

Ensure your design is compatible with testing. If you incorporate testing into your design strategy you’ll be able to achieve higher levels of coverage more easily.

Examine the status of development. If the testing is going to apply to legacy code that you don’t have the resources to work on it – reduce the coverage.

A Baseline for Code Coverage

The more complex the level of testing – the less code coverage you can expect to achieve. Unit-tests are the simplest form of testing, integration testing is more complex and system testing more complex still.

A good baseline for code coverage would be 90%/80%/70% for unit-testing, integration testing and system testing respectively.

You may use a wide variety of coverage metrics (line, block, decision, modified decision) at a macro level they should all have approximately equal levels of coverage. Though you should expect noticeable variation across different areas of code at the micro level.