As our project gets bigger and bigger, we want to be certain that all our production codes have executed during tests. Thus, we need to look for automated metrics that can help us evaluate our goal. One of these metrics is the Code Coverage. There are many types of code coverage but let’s focus on one of the most popular, the Branch Code Coverage. Consider the following implementation of the FizzBuzz program (You can find the implementation in this link: https://github.com/Fragki/FizzBuzz) :
|
1 2 3 4 5 6 7 8 9 10 |
func fizzBuzz(number: Int) -> String { if isDivisibleBy(numerator: number, denominator: 3) && isDivisibleBy(numerator: number, denominator: 5) { return "FizzBuzz" } else if isDivisibleBy(numerator: number, denominator: 5) { return "Fuzz" } else if isDivisibleBy(numerator: number, denominator: 3) { return "Fizz" } return "\(number)" } |
How many branches can we spot? Each if counts as 1, so if we have 3 branches from the if clause plus one from the return line, the total is 4. Branch code coverage evaluates if the branch is executed by tests at least once. This means that we will need at least 4 tests in order to get 100% code coverage for this method. We can see that branch code coverage is correlated to the Cyclomatic complexity.
How to enable Code Coverage in Xcode
Enabling code coverage in Xcode is easy. All we have to do is select the Target and edit the scheme:
Then select Test and enable the Code Coverage:
Press CMD + U to run all the tests.
If we go to a file, we can now see some numbers on the right side of the executable lines. These numbers show how many times this line has been executed during the tests.
And if we want to see the test report for all classes in our project, we should visit the Report Navigator:
Let’s say that in our FizzBuzz implementation we have forgotten to write the test for Number 15. By running the tests, we immediately see a red rectangle to the right of our code. This tells us that this logic has not been tested:
Does 100% code coverage mean that our code has been fully tested?
Absolutely not! Code coverage is an indication of the tests’ quality, not an absolute metric. It can, however, tell us which part of the code has not been tested. Let’s look at some examples where the code coverage is 100% but the code has not been fully tested.
We will once again use the FizzBuzz implementation as an example. Let’s assume now that the requirements have changed and the business requires the FizzBuzz to return “FizzBuzz” only if the number is a multiple of 3 and 5 but not the number 30. Our implementation will look like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
struct FizzBuzzCalculator { func fizzBuzz(number: Int) -> String { if isDivisibleBy(numerator: number, denominator: 3) && isDivisibleBy(numerator: number, denominator: 5) && number != 30 { return "FizzBuzz" } else if isDivisibleBy(numerator: number, denominator: 3) { return "Fizz" } else if isDivisibleBy(numerator: number, denominator: 5) { return "Buzz" } return "\(number)" } func isDivisibleBy(numerator: Int, denominator: Int) -> Bool { return numerator % denominator == 0 } } |
After running the tests, we get a 100% test coverage, but we know that a test is missing. We know that the input for number 30 has not been tested. So, the code coverage does not guarantee that all the necessary tests are in place, it is just a good indicator. We should be very careful when testing code with complex if statements or methods with many arguments.
