Skip to content

Testing

Gourav Mittal edited this page Oct 10, 2026 · 4 revisions

Put each test in the cheapest layer that can prove the behaviour. Full detail: test plan.

Layer Proves When
L1 Unit Parser, planner, diagnostics, fix-its, ranking Every commit
L2 Contract Each side of each contract alone: engines vs. oracles, messages vs. the schema Every commit
L3 Daemon integration The whole daemon over stdio: indexing, freshness, cancellation, crashes Every pull request
L4 End to end Every mock's behaviour in a real VS Code Smoke on PRs, full on merge
L5 Performance and soak Budgets, memory, long runs Nightly
L6 Release Install and first run on clean machines Each release candidate

Oracles

  • ripgrep checks working-tree results; git log -G checks history results.
  • Fixture repos in testdata/workspace/ match the Screens, and daemon tests run the mocks' queries.

The webview in Chromium

webview/test drives the real bundles in Chromium, in the page webviewPage.ts writes for VS Code and under its content security policy, with a stand-in for VS Code's API bundled ahead of each page's code. Anything the policy would block in the editor (an inline style or script, a resource from elsewhere) fails the test that caused it.

Spec coverage

Tag each test with what it proves: // @covers op:since diag:unclosed_paren, rpc:search/start, screen:file-names-only. scripts/specCoverage.mjs lists anything untested; --strict gates releases.

Seeing the panel without VS Code

node scripts/screenshotPanel.mjs --query 'retry_policy' --out panel.png

Renders the real daemon, controller and webview in Chromium, to compare against the mocks.


Next: Screens: every mock, with the built panel beside it.

Clone this wiki locally