> For the complete documentation index, see [llms.txt](https://help.aikido.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aikido.dev/changelog/q3-2026/code-coverage-find-what-your-tests-miss.md). # Code Coverage: find what your tests miss 23 Sep 2026 Code Coverage brings test coverage into Aikido Code Quality, free on every paid plan. Set up the integration in 1 simple step, run your test suite in CI, and see exactly where you’re lacking coverage per repository, per file, and per line, together with the code quality findings for the same code. {% embed url="" %} ### What it does * **Lists every repo.** Each row shows overall coverage and when it last updated, so the under-tested repos stand out. * **Goes down to the line.** Open a file to see line by line what your tests went through and what they never touched. * **Tracks coverage over time.** Each upload shows in the trend graph, so you can see the coverage evolution as you add tests or remove dead code. * **Reuses your existing SCM integration.** Add one upload step to your CI and results show up in Aikido, with nothing to host and no token to manage. * **Gives you two ways to browse.** The ‘Code Tree’ tab follows your directory structure, while the ‘File List’ tab shows every file, ranked by coverage percentage. ### What you can use it for * **Deciding where to invest in testing.** Hotspots with no coverage usually deserve attention before files that already have plenty. * **Checking a file before you touch it.** See what your tests already cover in the code you're about to change. * **Pairing coverage with security findings.** When a repository scan or PR check flags a file, check whether it has any tests running. ### How it fits into Aikido * Lives under **Code Quality > Code Coverage**, next to repositories and PR checks. * Native integrations for GitHub, GitLab, Bitbucket, and Azure DevOps. Other CI like CircleCI and Jenkins upload through a custom integration. * Accepts LCOV and Cobertura reports. Jest and pytest-cov write LCOV natively, and other runners work if they can export either format. * Keeps your source code out of the upload. The report only records which files and lines your tests covered, tied to the commit and branch it came from. Code Coverage is set up per repository. Add the upload step for your CI after your test step, point it at your coverage report, and the next pipeline run will populate the ‘Code Coverage’ tab in Aikido. The [docs](https://help.aikido.dev/code-quality/code-coverage) have the setup for each platform, including the [GitHub Action](https://github.com/AikidoSec/code-coverage-github-action) and the [GitLab CI component](https://gitlab.com/aikido-security/code-coverage-gitlab-action). If coverage is split across services, pass every file and Aikido merges them for you. Coverage shows in the dashboard, and on GitHub it can gate your PRs today: a pull request that drops coverage below your threshold won't merge. Other platforms are coming soon. ### How much does it cost? Code Coverage is included on every paid plan, Basic through Enterprise, with no per-line-of-code metering. It isn't available on the free forever Developer plan. → Read more about [Code Coverage](https://help.aikido.dev/code-quality/code-coverage) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://help.aikido.dev/changelog/q3-2026/code-coverage-find-what-your-tests-miss.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.