Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Code Coverage

Introduction

Code coverage is a test which shows how much of the codebase gets automatically tested. There are two main metrics - Function and Line - both given as percentage points. We use Rust’s testing function which comes with cargo, and GRCov to generate the reports.

Line Coverage

Line coverage gives the percentage of lines that were run during testing of all the lines total. It will show which lines were ran during testing, and which were not.

Function Coverage

Function coverage gives the percentage of compiler functions that were run during testing.

A simple function with no procedural macros will count as one function. However, a function can be extended (e.g. with #[derive(Debug)]) which when compiled appear as extra LLVM functions. This extra implementation is counted as another function by the coverage report, which means even though you see a single function signature, the report says there are multiple functions. There is no need to test implementations generated by #[derive(..)] since those implementations are not written by us.

How to Test

There are two ways of interrogating code coverage:

  • Push your commits to the remote, and look at the PR
  • Run tools/coverage.sh, and open target/debug/coverage/index.html in a browser

The second option (the coverage script) gives a much more verbose breakdown for which areas of the repo are starved of testing, breaking down to each and every line.

How to Improve

There are numerous way of improving our current code coverage. Below are some some considerations.

Test-as-you-go

TL;DR - leave the repo in at least as good a condition as you found it. Make sure whenever you commit something, that you add sufficient tests for it such that the coverage isn’t worse than before. This is very easy to forget!

Search and Destroy

Use the coverage script to find which files are badly covered, and add tests for them.

Quirks and Implications

Cloning (instead of Forking) the Repository

For the most up to date testing advice, look at the contributing guide. As of December 2025, we primarily work by cloning the main repository instead of working in our own forks. To prevent remote code execution, GitHub prevents a GH Action from running code on a fork. This means that our Action for reporting test coverage whenever you push your commits only works if your upstream branch is in the main repository (and not your own fork of it).