Automate the link between your test results and your test cases

We’re closing the loop on test automation. Testmo has always let you submit automated test results and link them back to the manual test cases in your repository — so a single case shows both its manual and automated coverage in one place. Until now, that second step was manual: you’d open a case and pick the automated tests it maps to. With this release, that linking happens automatically as part of your CI/CD pipeline.

The new @testmo/testmo-link command-line tool connects your automated test results to your repository test cases on every run — no manual mapping, no drift as your test suite evolves. Whether you’re maintaining coverage across a few hundred cases or tens of thousands, your repository stays in sync with what your automation actually tests.

This works alongside the @testmo/testmo-cli tool you already use to submit results. testmo-cli gets your automated results into Testmo; testmo-link connects them to your repository cases. They’re separate, standalone tools — install and use whichever you need.

How linking works

Testmo links automation to your repository in two tiers:

• Tier 1 — results to automation cases. When you submit automated results, Testmo automatically groups them into automation cases. This has always been automatic and needs no configuration.
• Tier 2 — automation cases to repository cases. This is the step @testmo/testmo-link automates. It matches each automated test to the repository test case (or cases) it corresponds to, and creates the link.

Once a link exists, the repository case shows its automation coverage and its latest automation status automatically — so your repository reflects real, current automation state without anyone maintaining it by hand.

Three ways to link

You choose how tests map to cases, and you can combine all three methods in a single run:

Source-code annotations. Add a comment above a test — @TestmoId: 1234 — and the tool links that test to case 1234. This keeps the mapping next to the test itself, versioned with your code. A single test can link to several cases: list multiple IDs (@TestmoId: 100, 200, 300), or use several annotation lines.

Config-file mappings. Map test names to case IDs in a YAML or JSON config file. Useful when you can’t (or don’t want to) edit the test source, or when the mapping lives outside the codebase. Where two tests share a name across different files or suites, file and folder keys disambiguate them.

Test-name pattern matching. Match tests to cases by name, so new tests that follow your naming convention link automatically without any per-test annotation or config entry.

Matching is name-based: the tool reads your test names and maps them to cases, rather than relying on line numbers or file positions that shift as code changes.

Broad framework support

@testmo/testmo-link reads the same test output your CI already produces, across the major frameworks and languages:

• JavaScript/TypeScript — Jest, Vitest (including test.each parameterized tests), Playwright (including fixture-based tests), Cypress, Mocha
• Python — pytest (including parameterized tests)
• Java — JUnit (including JUnit 5 parameterized tests)
• C# — NUnit
• Ruby — RSpec
• BDD — Cucumber / Gherkin .feature files

…and more. If your framework produces standard test output, the tool can link it.

New API endpoints

The same linking capability is available directly through the API, so you can build your own workflow if the CLI doesn’t fit your setup:

Example usage

Add @testmo/testmo-link as a second step in your CI pipeline, right after you submit results. The testmo-cli submit command prints the run ID; pass it straight into testmo-link:

# 1. Submit your automated results (as you already do)
run_id=$(npx @testmo/testmo-cli automation:run:submit \
  --instance https://your-instance.testmo.net \
  --project-id 1 \
  --name "CI run" \
  --source "unit-tests" \
  --results results/*.xml)

# 2. Link those results to your repository cases
npx @testmo/testmo-link \
  --instance https://your-instance.testmo.net \
  --project-id 1 \
  --run-id "$run_id" \
  --config testmo-linking.yml

Preview what would be linked without writing anything, using --dry-run:

npx @testmo/testmo-link \
  --instance https://your-instance.testmo.net \
  --project-id 1 \
  --run-id 87 \
  --config testmo-linking.yml \
  --dry-run

A minimal config combining annotations and pattern matching:

annotations:
  enabled: true
  paths:
    - "tests/**/*.py"

pattern_matching:
  enabled: true
  rules:
    - type: name_match

What this means for teams

For teams running automated tests in CI/CD: your repository coverage now maintains itself. Add the linking step once, and every pipeline run keeps your test cases mapped to their automation — no periodic manual reconciliation, no coverage reports drifting out of date as tests are added, renamed, or removed.

For teams with large or fast-moving suites: pattern matching and bulk linking mean you don’t pay a per-test cost. New tests that follow your naming convention link automatically, and thousands of links go up in a single API request.

For teams building their own tooling: the linking API is available directly. The same endpoints the CLI uses are open to you, so you can integrate linking into a custom workflow or an existing internal tool.

Getting started

Install the tool globally (it requires Node.js 20 or later):

npm install -g @testmo/testmo-link

Then add it to your pipeline after your results submission step. The full setup guide walks through authentication, all three linking methods, and CI examples.

We want your feedback

Automation linking is a foundational piece of how Testmo connects your automated testing to your test management — and we’re keen to hear how it fits your workflow. If you’re linking automated tests to your repository, or planning to, we’d love your input on the frameworks, config options, and matching behaviour you need. Let us know!