When we write new code, there can be quite a large margin for error, so It’s incredibly important to test your code, and to know just how much of it you’ve tested. Code coverage tells you how much of your code has been exercised by the tests, which means you know how much additional testing you need to do. Generally, you want to aim for at least 90% code coverage.

So how do you know what your code coverage actually is? Well, there are a few tools you can use to find out your code coverage. Clover and Istanbul are popular examples. You can use these tools to generate four different kinds of coverage metrics.

Method coverage is the simplest, which just gives you the percentage of the methods that have been covered. This is useful information, but can also be inaccurate, as it only focuses on a specific point, so it might not help with the overall bigger picture. Symbol coverage gives you the percentage of sequence points (statements) that have been exercised. This is better than method coverage, but it does have a weakness in that it doesn’t show if both sides of a Boolean condition, like an ‘if’ statement, have been tested.

Branch coverage gives you the percentage of completely executed blocks in a method. This is a higher level coverage than symbol coverage, as one block can have multiple statements in it. It’s also more accurate, as both sides of a Boolean condition are tested. Last up, cyclomatic complexity tells you the number of tests you’ll need to do to get 100% branch coverage. If you have methods that have a cyclomatic complexity of 15 or more, your methods are too complex, and should be refactored.

While all these coverage metrics are great, you need to remember that percentage isn’t everything. For instance, your methods might be covered, but have all of your edge/corner cases been tested properly? Or maybe you’ve used a test generation tool that gives you 100% test coverage, but the tests are actually worthless and don’t really show you that the code works. Finally, failing tests also count towards test coverage. So you could have 100% test coverage, with code that failed every test. With this in mind, you should only use test coverage tools to help you identify areas of code that need testing, or that are too complex.

To make sure that you know what to test, and how to test correctly, we recommend using the 'Right B.I.C.E.P' acronym. These guidelines can help you make sure that your coverage isn’t just high, but that your code is passing too. ‘Right’ is pretty simple. Ask yourself, ‘are the results right?’. Let’s run through the rest quickly:

B - Are all the boundary conditions correct?

I - Can you check the inverse relationships?

C - Can you cross-check results using other means?

E - Can you force error conditions to happen?

P - Are performance characteristics within bounds?

And that's it for this video. Code coverage is something you'll be using a lot but it's important to make Sure you use the right methods, and know what to test, to get real value out of it.