Testing

Test layers

Layer	Use it for	Main entry point
Playwright	Resolver UI behavior in a real browser with temp conflict repos	npm run test:pw
VS Code host	Extension-host behavior such as commands, status indicators, and Git integration	npm run test:vscode
E2E resolution	Full extension host + web server + browser + notebook write path	npm run test:e2e
Manual sandbox	Debugging a real fixture by hand in VS Code	npm run test or node ... --manual ...

As a rule of thumb, prefer Playwright for resolver behavior and move to the VS Code host only when the test needs real VS Code APIs, command wiring, or Git state that should be exercised through the extension.

CLI commands

# Interactive TUI picker
npm run test

# Everything
npm run test:all

# Resolver UI integration tests
npm run test:pw

# VS Code extension-host regression tests
npm run test:vscode

# Full end-to-end resolution flow
npm run test:e2e

npm run test, npm run test:vscode, and npm run test:e2e all go through apps/vscode-extension/tests/runIntegrationTest.ts. npm run test:pw calls Playwright directly.

Compile behavior

Compile before using direct runners

The npm test scripts already run compile and compile-tests through their pretest:* hooks.

If you run node out/..., npx playwright test, or editor-integrated test commands directly, compile both layers first:

npm run compile
npm run compile-tests

Direct runner usage

# Run all Playwright specs through the shared runner
node out/apps/vscode-extension/tests/runIntegrationTest.js --playwright

# Run one Playwright spec by basename
node out/apps/vscode-extension/tests/runIntegrationTest.js --playwright perCellResolution

# Run the VS Code regression suite
node out/apps/vscode-extension/tests/runIntegrationTest.js --vscode

# Run the full E2E resolution test
node out/apps/vscode-extension/tests/runIntegrationTest.js --e2e

# Open a manual sandbox from test-fixtures/
node out/apps/vscode-extension/tests/runIntegrationTest.js --manual general/conflict_0

Running npm run test with no flags opens the interactive TUI for the same modes, including fixture-backed manual sandboxes.

Key files

File	Purpose
apps/vscode-extension/tests/runIntegrationTest.ts	Shared CLI/TUI runner for Playwright, VS Code host, E2E, and manual sandboxes
packages/web/tests/fixtures.ts	Playwright fixtures for conflict repos, resolver sessions, and disk assertions
apps/vscode-extension/tests/testHarness.ts	VS Code host helpers for launching the resolver and validating written notebooks
apps/vscode-extension/tests/e2eResolution.test.ts	Full-stack resolution test inside the VS Code extension host
test-fixtures/shared/integrationUtils.ts	Shared browser helpers, including UI-to-disk expectation builders
test-fixtures/shared/repoSetup.ts	Temp merge-conflict repo creation from notebook triplets

Adding a new test

testing efficiency

VS Code tests:

1. are significantly more computationally expensive than playwright, and causes the CI to take much longer
2. have terrible logging in comparison to playwright tests, and cannot be parallelized unlike playwright.

1. Choose the lowest layer that proves the behavior.
   • UI behavior in the resolver: add a Playwright spec under packages/web/tests/.
   • Extension commands, status, or Git integration: add a VS Code host test under apps/vscode-extension/tests/.
   • Cross-boundary resolution flow: extend or add an E2E-style host test.
2. Reuse the existing fixture triplets under test-fixtures/ when possible. Add a new fixture only when the behavior needs a new notebook shape.
3. Respect settings explicitly. Tests that depend on auto-resolve or UI toggles should set them through the existing helpers rather than assuming defaults.
4. Verify that the notebook written to disk matches what the UI showed. The existing helpers already support the expected pattern:
   • build expected cells from the live UI
   • apply the resolution
   • assert the final notebook matches those cells
5. Keep core merge behavior in packages/core. Docs and tests should reflect that split rather than re-creating merge logic in the harness.

For suite-specific details, see Playwright and VS Code host.