Code coverage reports for Swift Packages

Our team is trying to maintain code coverage that is not less than 70%. To make sure we remember this agreement, we decided to integrate a tool that will report what is the code coverage with the changes we made in the pull request. Here, we will share how you can add this tool to your project.

Code coverage report

In this tutorial, we will add code coverage reports to Swift Package and visualize it in Github pull requests using Fastlane code coverage reporting plugin xcov.

Steps:

1. Add Fastlane to your Swift Package
2. Add lane to run tests and generate code coverage
3. Integrate Danger plugin
4. Connect CI with Danger plugin

Add Fastlane to your Swift Package

Navigate to your package folder in the terminal and run the following command:

$ fastlane init

After running it, you should see new files in your folder: Fastfile, Gemfile, and Appfile.

In order to run tests in Fastlane, we will need to generate xcodeproj folder for our package. You can do that by running this command in your package folder:

$ swift package generate-xcodeproj

Add Fastlane lane to run tests and generate code coverage

In the new Fastfile we will create a lane that runs the tests, generates result bundle, and shows the code coverage analysis.

First, let’s add xcov dependency to the Gemfile:

Then, add the following lane to your Fastfile:

We used a scan to run the tests with code coverage option enabled. The results of the tests are generated to the result bundle and xcov uses it to output the code coverage.

If we run the lane locally, we see the xcov Coverage Report:

So now we have everything working locally. Let’s integrate this into our CI/CD process and visualize code coverage report in the GitHub pull request.

Integrate Danger plugin

Danger is a ruby gem that helps to automate common code review tasks. It runs during the CI process and executes the tasks you put in its native file called Dangerfile. Danger can run on CI services like CircleCI, Travis, Jenkins, and many others. It also supports SCMs like GitHub, GitLab, Bitbucket Server, and VSTS. For more information, check their website https://danger.systems/ruby/.

First, we need to add some dependencies to the Gemfile. We will use Danger for the automation and danger-xcov plugin to visualize code coverage in the PR. Add the following lines to your Gemfile:

gem "danger"
gem "danger-xcov"

Then, create a file named Dangerfile in your root Swift package directory. Add the following code to the Dangerfile:

We need to add a direct path to the Xcode code coverage report (xccov_file_direct_path) because danger-xcov doesn’t find it itself. The report name might be different based on your machine.

Add Danger to the CI

Now, we will add Danger to our CI process and visualize code coverage reports in the pull requests.

In this tutorial, we will be using CircleCI as the CI service. If you need another service, check the instructions on the Danger website.

First, we need to execute Danger while running the CI. Add the following step to your CircleCI job config.yml file to run the Dangerfile:

- run:
name: Run code coverage report tool
command: bundle exec danger --verbose

This step should be run after you execute the lane unit_testing that we added before. The sequence of the steps should look like this:

Connect CI with Danger plugin

Now that we added the steps to show the coverage report, we need to authorize Danger to post comments in your Pull Requests. You will need a GitHub account that will act as a bot to do so. It is suggested to create a new GitHub account, but you can also use your own. Follow the steps below to enable comment posting.

In Github account:

Add personal access token for Danger GitHub access and select repo and write:discussion scopes. This account should be added as a contributor to your project.

In CircleCI project settings:

1. Add that GitHub token value to Environment Variables with the name DANGER_GITHUB_API_TOKEN.
2. Add API Token in API Permissions section. Add a label DANGER_CIRCLE_CI_API_TOKEN and scope status.
3. Enable ‘Only build pull requests’ option in Advanced settings.

With these pieces in place, Danger should be able to post comments in your Pull requests.

If you run the job for your pull request, the result should look as follows:

Get the full source code in Github.

GitHub — neringga/CodeCoverageTutorial