With the introduction of Xcode 7, Apple has greatly improved its testing tools. One of the tools newly introduced with Xcode 7 is Code Coverage. The Code Coverage tool aims to provide us with insights about how thorough our tests are. Not only that, it also informs us about which parts of our code are tested in our unit tests and which parts of our code aren't.
To enable Code Coverage, first open the scheme editor through the Product | Scheme menu as shown in the following screenshot:
Select the testing action and make sure the Gather coverage data checkbox is checked as shown in the following screenshot:
After doing this, close the scheme editor and run your tests. This time, Xcode will monitor which parts of your code have been executed during this tests, and which parts haven't. This information can give you some good insights about which parts of your code could use some more testing. To see the coverage data, open the Report navigator in the leftmost sidebar in Xcode. The rightmost icon in this sidebar represents the Report navigator as shown in the following screenshot:
If you expand the controls for your app, you can select the test report. This report will open in the Editor area of Xcode and you'll be presented with three tabs: Tests, Coverage, and Logs. We're only interested in the Coverage tab right now. If you select this tab, you're presented with several bars that are filled to indicate the amount of code tested in the corresponding file. The following screenshot shows Coverage for the MovieTrivia app:
The more a bar is filled, the more lines of code in that file or method were executed during your test. You'll notice that our AppDelegate.swift file is covered under the tests even though we haven't written any tests for it. The reason this happens is that the app must launch during the test to act as a host for our tests. This means that parts of the code in AppDelegate.swift are actually executed during the test and therefore Xcode considers it covered in the tests.
If you expand the AppDelegate.swift file you'll see that a lot of methods are not tested at all. If you open up the AppDelegate.swift file, you can see that these untested methods are, in fact, empty methods. To improve your test coverage and to avoid accidental bugs, you should remove these empty implementations.
One last feature of Code Coverage that's worth mentioning is inline Code coverage. Inline Code coverage will show you how often a certain block of code has been executed during testing. This will give you insights into your code coverage inline, in your files, without having to navigate to the Reports navigator. To enable this feature, open up your Xcode preferences and navigate to the Text Editing
tab. Check the Show iteration counts checkbox at the bottom of the tab. If you open a file now, you'll see the iteration count for your code on the right side of the editor window. The following screenshot shows the iteration count for the loadQuestions(callback:) method:
Even though Code Coverage is a great tool for gaining insights into your tests, you shouldn't let it influence you too much. Regularly check the Code Coverage for your app and look for methods that are untested and are either easy to write tests for or should be tested because they contain important logic. Code Coverage is also great for discovering parts of your code that should be tested but are hard to test because they're nested deep inside a view controller, for example.
What you should not do is aim for a full 100% coverage. Doing this will make you jump through crazy hoops and you'll invest way more time in testing than you should. Not all paths in your code have to be tested. However, don't shy away from doing some refactoring like we've done before. Proper testing helps you to avoid bugs and structure your code better. Code Coverage is just one extra tool in your tool belt to help identify which parts of your code could benefit from some tests.
If we look at the current state of the coverage in the MovieTrivia app, we're actually doing quite well. Most of the logic in the app is tested. The only part of our app that's not tested thoroughly is the view controllers. If you're using storyboards, like we are, it's not necessarily easy to test view controllers. Even if you opt for an all-code approach where you omit storyboards and write all of your layout purely in code, it can be tedious to test your view controllers.
Luckily, there is one last testing tool that we'll discuss in this chapter; XCUITest.