Code Coverage

To set up code coverage, you need to activate the code health feature on your account. Once done, follow the below-mentioned steps to get started with code coverage-

Navigate to the code coverage section to get your account token details.

We evaluate the overall repository coverage in Code Coverage to provide better insights into PR coverage. Since we show the change in coverage caused by a PR, we need the repository's baseline coverage value. The repository coverage should also be updated whenever there’s a change in the master/default branch. You can set this up as part of your deployment to trigger the coverage run whenever something is pushed or merged into the master/default branch.

1. Creating Coverage Reports

Before you can use Typo to show code coverage metrics for your project, you need to run tests and use tools to generate reports that show how much of your code is covered by tests. Consider these points when generating coverage reports:

• There are various tools available for generating coverage reports, but you need to make sure that the reports are in a format that Typo can understand.

• Ensure that your coverage reports include data for all the code files that were tested, not just the ones that were changed in each commit.

• Below is a table of example coverage tools that produce reports in formats supported by Typo:

2. Uploading coverage data to Typo

Once you've configured coverage reports, you must utilize the Typo Coverage Script to upload them to Typo. The best practice for this task is to employ a CI/CD platform that automatically executes tests, generates coverage reports, and then employs the Typo Coverage Script to upload the coverage information to Typo.

Step 1

Add Typo Access Token to your environment variable as TYPO_ACCESS_TOKEN

export TYPO_ACCESS_TOKEN=a0ac0e20-62d9-xxxx

Step 2

Add Typo Client ID to your environment variable as TYPO_CLIENT_ID

export TYPO_CLIENT_ID={b21ed0a2-xxxx}

Step 3 (optional)

To specify the branch for the coverage report as an environment variable

Github Actions - env: GITHUB_HEAD_REF: ${{ github.head_ref }} Jenkins - export GITHUB_HEAD_REF=$(git rev-parse --abbrev-ref HEAD) echo "GITHUB_HEAD_REF=${GITHUB_HEAD_REF}" Circle CI - jobs: build: docker: - image: circleci/python:3.8 steps: - checkout - run: name: Set GITHUB_HEAD_REF command: | echo "export GITHUB_HEAD_REF=${CIRCLE_BRANCH}" >> $BASH_ENV - run: name: Print GITHUB_HEAD_REF command: | source $BASH_ENV echo "GITHUB_HEAD_REF is $GITHUB_HEAD_REF" # Add more steps as needed

Step 4

To ensure that your code coverage metrics are collected and reported accurately, you need to add the coverage step to your build process. This step involves running the following bash command after your tests have been executed, during your build process to upload the coverage report:

bash <(curl -Ls https://typo-website-static.s3.ap-south-1.amazonaws.com/typo-coverage.sh) REPORT_PATH --head=$GITHUB_HEAD_REF

REPORT_PATH: This should be replaced with the actual path to your coverage report file.

GITHUB_HEAD_REF: This field is optional. Consider STEP 3 to get the branch name.

You need to execute this command at two specific points in your development workflow:

• During Production Builds: This ensures that coverage data is collected for the code being deployed to production.

• During Pull Request (PR) Creation or Modification: This helps to track and verify coverage for changes introduced by the PR.