VS Code host tests

VS Code host tests live in apps/vscode-extension/tests/. They run inside a real VS Code Extension Development Host via @vscode/test-electron, which is the right layer for command wiring, status indicators, and vscode.git behavior that does not exist in the browser-only Playwright setup.

What belongs here

Use this layer when the test needs real VS Code APIs, extension activation behavior, or Git integration that should be exercised from the extension side.

There are two main modes:

• test:vscode: regression tests for extension-host behavior
• test:e2e: the full extension host + web server + browser + notebook write path

CLI commands

npm run test:vscode
npm run test:e2e

# Direct runner usage after compiling
node out/apps/vscode-extension/tests/runIntegrationTest.js --vscode
node out/apps/vscode-extension/tests/runIntegrationTest.js --e2e

Both commands run through apps/vscode-extension/tests/runIntegrationTest.ts.

Compile behavior

Compile before direct runner usage

npm run test:vscode and npm run test:e2e already compile the repo through pretest:vscode and pretest:e2e.

If you run the compiled runner directly, compile both layers first:

npm run compile
npm run compile-tests

Key files

File	Purpose
apps/vscode-extension/tests/runIntegrationTest.ts	Shared CLI/TUI runner for host tests, E2E, and manual sandboxes
apps/vscode-extension/tests/vscodeRegression.test.ts	Batches the extension-host regression tests into one VS Code launch
apps/vscode-extension/tests/e2eResolution.test.ts	Full-stack resolution test inside the extension host
apps/vscode-extension/tests/testHarness.ts	Opens the conflict resolver and validates notebooks written to disk
apps/vscode-extension/tests/settingsFile.ts	Writes test-specific MergeNB settings
apps/vscode-extension/tests/gitTestUtils.ts	Shared Git helpers for host-side assertions

E2E flow

e2eResolution.test.ts boots:

1. A temp Git repo with a three-way merge conflict.
2. The extension host pointing at that repo.
3. The real web server.
4. A headless browser that clicks through the resolver.
5. Assertions against both the UI state and the on-disk notebook.

This is the test that would catch a WebSocket contract break between client and server.

Adding a new VS Code host test

1. Add the test under apps/vscode-extension/tests/.
2. Put pure extension-host regression coverage into the regression suite, and keep full-stack browser resolution coverage in E2E-style tests.
3. If the new test is a host regression case, export a run() function and wire it into vscodeRegression.test.ts.
4. If the test changes settings-sensitive behavior, set those values explicitly with writeSettingsFile(...) rather than assuming defaults.
5. If the test writes a notebook, verify that the final file matches what the UI showed by using the existing helpers such as collectExpectedCellsFromUI(...) and assertNotebookMatches(...).

e2eResolution.test.ts is the best example when you need the full browser-backed resolution path. vscodeRegression.test.ts is the best example when you want one more host-only regression in the shared sequential launch.

Manual sandboxes

The same runner can also open a real manual sandbox from test-fixtures/. This is useful when you want to inspect a fixture by hand in VS Code instead of turning it into an automated test immediately.

node out/apps/vscode-extension/tests/runIntegrationTest.js --manual general/conflict_11
MERGENB_MANUAL_SANDBOX_DIR=/tmp/foo npm run test -- --manual general/conflict_11

The --manual argument accepts a fixture folder such as general/conflict_11, and the interactive npm run test TUI lets you pick from discovered fixtures without remembering the path.