Mono multiple-repositories. Multiple mono-repositories. Single test workflow.

$ cargo install cargo-llvm-cov --locked
$ rustup component add llvm-tools-preview

Install Node dependencies before the run, for example pnpm install in a pnpm workspace. Browser tests also need the browsers named by the Playwright config.

$ cherry-test --init-only
$ cherry-test
$ cherry-test --no-open

Coverage and the browser report are on by default. --no-open leaves the report on disk. With the default paths, open target/cherry-test/latest/reports/index.html. The terminal prints the same path.

defaults:
  coverage: true
  html_report: true
  runs_base: target/cherry-test/runs
  scope: global
  diff_base: main

adapters:
  shop:
    command: cargo
    args: [run, --target-dir, target/adapter, -p, shop-adapter, --quiet, --]
    timeout_secs: 1800

projects:
  shop:
    path: .
    diff_base: main
    compose: docker-compose.test.yml
    packages:
      shop-rs-api:
        kinds: [unit, integration]
        integration:
          adapter: shop
          scope: shop_checkout
      shop-ts-lib-cart:
        runtime: node
        manifest: shop-ts-lib-cart/package.json
        kinds: [unit, integration]
        unit:
          command: pnpm
          args: [exec, vitest, run, --coverage, src]
          cwd: shop-ts-lib-cart
        integration:
          command: pnpm
          args: [exec, vitest, run, --coverage, integration]
          cwd: shop-ts-lib-cart
      shop-ts-web-react:
        runtime: node
        manifest: shop-ts-web-react/package.json
        kinds: [unit, functional, visual]
        unit:
          command: pnpm
          args: [exec, vitest, run, --coverage]
          cwd: shop-ts-web-react
        functional:
          adapter: shop
          scope: shop_checkout
        visual:
          adapter: shop
          scope: shop_checkout
    services:
      api:
        service: shop-rs-api
        port: 3000
        health: /health
      db:
        service: shop-db
        port: 5432
        kind: postgres

scopes:
  shop_checkout:
    projects: [shop]

cherry-test.yml and cherry-test.toml are accepted. --init-only scans six directory levels for Cargo, Vitest, Maven, Gradle, and CMake packages, common Compose filenames, and #[cherry_test] scopes. It skips .git, target, and node_modules. --force-init rewrites cherry-test.yaml; review that diff. For an unusual layout, edit the file and pass --root.

A functional or ui block uses command, args, and cwd, and the kind has to appear in kinds. Set adapter: playwright on a browser phase to import results and screenshots. Strict runs require individual test results. The command adapter's exit-status check is for non-strict runs.

Add TestEnv with these dev-dependencies. The macro uses tokio and anyhow in the package under test. In this checkout, shop-rs-api points cherry-test-core at test/cherry-test-core instead of the git source. Commit the lockfile.

[dev-dependencies]
anyhow = "1"
cherry-test-core = { git = "https://github.com/lmrrcc/cherry-test", branch = "main" }
tokio = { version = "1", features = ["macros", "rt-multi-thread"] }

The checkout test opens a cart, adds three units of NB-DOT-A5, posts checkout, and checks the order total and the stock decrease. Names follow {project}_project_{suite}_suite_{test}_test. The macro requires an async function, one env: TestEnv argument, and no declared return type. ? is allowed in the body. Ordinary cargo test sees these tests as ignored. Cherry Test selects them in the integration phase. The React storefront covers the same API again with functional tests and visual snapshots: the catalog, cart lines, checkout, and the rejection cases.

use cherry_test_core::prelude::*;

#[cherry_test(scope = "shop_checkout")]
async fn shop_project_checkout_suite_places_order_and_decrements_stock_test(env: TestEnv) {
    let stock_before = stock_of(&env, "NB-DOT-A5").await?;
    let cart_id = open_cart(&env).await?;
    add_item(&env, &cart_id, "NB-DOT-A5", 3).await?.assert_status(200);
    let response = env
        .project("shop")
        .service("api")?
        .post(&format!("/v1/carts/{cart_id}/checkout"))
        .send()
        .await;
    response.assert_status(201);
    let order = response.response_body_json()?;
    assert_eq!(order["total_cents"], 4200);
    assert_eq!(stock_of(&env, "NB-DOT-A5").await?, stock_before - 3);
}

Use framework mocks for a timeout or an unavailable third-party API, or add the mock server to Compose. Cherry Test runs the tests and services you configure. For a full path, run the real API and database, and add browser tests when the UI is part of the flow. A mocked dependency checks the behavior that mock represents.

Markers distinguish covered lines, uncovered lines, and lines with no coverage data. A covered line still needs an assertion that checks the behavior. Set diff_base to the branch or commit under review, and fetch it first. empty, empty-tree, and root compare the tracked tree with an empty Git tree. Discovery includes commits since the base, staged changes, unstaged changes, and untracked files.

The Shop discount change request is that comparison on a branch that touches the cart library, the API, and the React shop. Open the change report.

defaults:
  diff_base: origin/development

# .coverageignore at the configuration root
**/generated/**

Keep ignore rules narrow. An exclusion changes what the coverage percentage means, so review edits to that file with the tests.

1. Check out the change, submodules, and the target branch history.
2. Install project dependencies and coverage tools.
3. Start Docker when integration tests need containers.
4. From the configuration root, run cherry-test --strict --no-open.
5. Save reports/ and coverage/ from the run directory, including when the step fails. latest is a Unix symlink.
6. Review failures, skips, uncovered edits, and the assertions on the changed behavior.
7. Require the CI checks and the code review before the merge.

$ set -euo pipefail
$ export CI=true
$ cargo llvm-cov --version
$ docker info >/dev/null
$ docker compose version
$ cherry-test --root app/shop --strict --no-open
$ test -s app/shop/target/cherry-test/latest/reports/index.html
$ test -s app/shop/target/cherry-test/latest/coverage/merged.lcov

Run that in a fresh checkout with coverage: true and html_report: true. Upload the run's reports/ and coverage/ under target/cherry-test/runs/. From inside app/shop the same files are target/cherry-test/latest/.... --strict rejects failed or skipped tests, empty required phases, missing requested coverage, and invalid adapter results. A normal run reports CRAP. A high score does not fail the run. Minimum coverage and mutation score stay separate required checks. Review edits to tests, ignore files, and package selection along with the product code.

A tool changes a comparison, a return value, or an operation, then reruns the tests. A change the tests catch is a killed mutant. A change that leaves the tests passing is a surviving mutant. Some survivors are missing tests. Some do not change observable behavior. Cherry Test starts that tool only when you pass --kinds mutation. Rust uses cargo mutants. C and C++ use Mull. Java and Kotlin use PIT. Node, React, and Vue use StrykerJS with Vitest. Keep that report next to the Cherry Test report and let the mutation tool fail the job.

$ cargo install cargo-mutants --locked
$ cherry-test --root app/mini --kinds mutation --no-open

Further reading: cargo-mutants, Mull, PIT, StrykerJS, and mutant states.

CRAP = complexity^2 * (1 - coverage)^3 + complexity

# complexity 10 → 110 at no coverage,
# 22.5 at half coverage, 10 at full coverage

A normal run calculates cyclomatic complexity for each function in measured source and reports CRAP in the terminal and the HTML report. Pass --no-crap to skip that calculation. Complexity starts at 1 and adds one for each if, loop, catch, switch case, match arm, &&, ||, and ternary. Coverage is the fraction of measured lines inside the function, not basis-path coverage. Rust, C, C++, Java, Kotlin, JavaScript, TypeScript, and Vue script blocks are scored. Crap load is 0 when the score is under 30, and complexity * (1 - coverage) + complexity / 30 when the score is at or above 30. A score of exactly 30 counts. The HTML report shows each function's complexity, measured-line coverage, CRAP, and crap load, then the workspace totals: function count, total complexity, total CRAP, mean, median, worst score, the count and percent at or above 30, and total crap load. Those totals are repeated per project when each scored file falls under one configured project path. The terminal prints the workspace totals and at most four of the worst functions, each with one source line, and then the suite summary. Files outside every project are labeled outside projects. A high score does not by itself fail the run.

$ cherry-test --root app/mini --no-open
$ cherry-test --root app/mini --no-crap --no-open

Further reading: Alberto Savoia's CRAP note.

target/cherry-test/
  latest -> runs/<run-id>/
  runs/<run-id>/
    coverage/
      <project>/
      merged.lcov
    reports/
      index.html
      phases.html
      integration/*.jsonl
      adapters/<project>/<package>/<phase>/
        request.json
        result.json
        coverage.lcov
    env.json

Files appear for the runners that ran. env.json records the service endpoints the runtime discovered. The runner loads .env.test from the configuration root when that file exists, or from the project-id directory. CI suppresses the automatic browser open.