[Sunrisepeak]

Every component is 1.3.0: the backend, mcpp-vscode, mcpp-clion and mcpp-nvim. The design is .agents/docs/2026-11-10-tests-from-mcpp.md, and the mcpp side is mcpp#917.

Tests as mcpp states them

Programs of several files. With [test] programs = "directory" (mcpp 2026.11.9.1), mcpp lists unit but runs unit/a and unit/b. 1.2 lost those results.

• Such a program is now shown with its files as children.
• A part's record is attributed to its program.
• mcpp states the parts with test-parts (mcpp#917). Before that, the backend derives them as 2026.11.9.1 forms them.

Cases.

• Each case carries its file, kind, tags, expectation and metric bounds, from mtest's manifest and the program's listing.
• A whole run marks every case.
• A run of cases reports every part's record, not only the last.
• xfail counts as passed, xpass as failed, invalid as errored.
• A failure with both sides is shown as a diff in VS Code, a comparison failure in CLion, and two lines in Neovim.

Live results and metrics (gated on mcpp#917):

• test-case-stream → test/caseEvent as each case begins and ends.
• test-metrics → metrics against their bounds: on the case's line in VS Code and Neovim, in its output in CLion.

Test Insights (mcpp.test.insights; test/insights, test/history):

• It reads the runs mcpp keeps in target/mtest.
• It shows the last run, failures and since when, metric trends against bounds, the slowest and the flaky cases, and the schedule with its critical path.
• VS Code shows it in a webview and CLion in a tool-window tab; both draw webui/tests.html. Neovim shows it as text.

Each editor in its own idiom:

• VS Code: Testing view and test tags (@kind:bench), diff messages, editor decorations.
• CLion: an ID-based SMRunner tree (parts that run at once get their own suites), and a JCEF page shared with the graph through JcefPage.
• Neovim: mcpp://tests written at most every 100 ms, signs and virtual text, the quickfix list, :Mcpp test.insights.

Compatibility.

• With any mcpp, programs and their results are shown.
• From 2026.11.8.1, cases are shown as well.
• From 2026.11.9.1, the files of a program and the insights are shown.
• A view that needs a feature the project's mcpp does not state is left out. capabilities/explain names the feature: tests.cases, tests.parts, tests.live, tests.metrics.

Speed. The suite types of a project's tests are read again only when its test files change. The store is read one run at a time, each run only once.

The backend's tests are mtest's (0.5.2)

• tests/unit, tests/e2e, tests/cts and tests/bench are each one program whose files declare their cases, with no main.
• Each test's data sits beside the cases that read it.
• cts/contracts holds the contracts against their schemas.
• tests/bench bounds the latency of three things: a keystroke in a manifest of 400 dependencies, reading a test file of 2000 cases, and the insights over 50 runs of 400 cases.
• testsupport's check is mtest's fatal expectation.
• CI puts mtest report of each run in the job's summary (.github/actions/mtest-report).

Versions and mcppls 0.21

• A change of the backend is a series release: every component at X.Y.0.
• release-plan.sh refuses:
  • backend-v* tags;
  • a backend other than $series.0;
  • a plugin patch when a path of the backend changed since v$series.0.
• mcpp-clion builds and tests against mcppls-clion-0.21.0.zip.
• The backend builds with mcpp 2026.11.9.1, mcpplibs.os 0.4.2 and mcpplibs.mtest.manifest 0.5.2.

Docs

README (EN/ZH): features, tests, compatibility. docs/architecture.md "A test run, end to end", the agent skill, CHANGELOG 1.3.0.

Co-authored-by: speak-agent 248744407+speak-agent@users.noreply.github.com