Unit Tests
Run VS Code repository unit tests the supported way—runTests tool first, or scripts/test.sh and test.bat with file and name filters.
Overview
unit-tests is an agent skill most often used in Ship (also Build) that documents how to run VS Code repo unit tests via runTests or scripts/test.sh and test.bat.
Install
npx skills add https://github.com/microsoft/vscode --skill unit-testsWhat is this skill?
- Prefer structured runTests tool with files, testNames, and coverage mode
- Fallback: ./scripts/test.sh (macOS/Linux) and scripts/test.bat (Windows)
- Bare absolute .ts/.js paths as positional args map to --run filtering
- Mocha runner via Electron download when needed
- Supports debugging-oriented test runs from repo root
- Two platform entry scripts: test.sh and test.bat
- runTests supports files, testNames, and mode=coverage
Adoption & trust: 141 installs on skills.sh; 186k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need to run or narrow VS Code unit tests but risk slow mistaken invocations without the repo’s supported tool and script conventions.
Who is it for?
Solo contributors or agent sessions actively patching the VS Code codebase who must verify changes with targeted unit tests.
Skip if: Generic open-source projects outside the VS Code repo or teams that only need integration/e2e Playwright flows without this Mocha harness.
When should I use this skill?
Running unit tests in the VS Code repo—prefer runTests; otherwise scripts/test.sh or scripts/test.bat with file and name filters.
What do I get? / Deliverables
You run the correct Mocha suites with file and name filters—or coverage—using runTests when present or the official shell scripts from repo root.
- Executed unit test run with pass/fail output
- Optional coverage collection via runTests coverage mode
- Correctly scoped test command documented for CI parity
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical home is Ship because the skill exists to execute and validate the test suite before merge and release. It documents unit test invocation, globbing, and coverage modes—pure testing workflow for the VS Code monorepo.
Where it fits
After editing editor model code, run src/vs/editor/test/common/model.test.ts with a name filter before opening a PR.
Before merge, invoke runTests with absolute paths and coverage mode on touched modules.
During review fixes, re-run only failing test names via testNames instead of the full Electron suite.
How it compares
Repo-specific test runner docs—not a portable unit-testing framework skill for arbitrary Node apps.
Common Questions / FAQ
Who is unit-tests for?
Developers and coding agents working in the microsoft/vscode repository who need authoritative instructions for local unit test execution.
When should I use unit-tests?
In Ship when validating a PR or fix with filtered Mocha tests; in Build when iterating on a module and you need a fast file-scoped test run before review.
Is unit-tests safe to install?
The skill describes standard repo test scripts; review the Security Audits panel on this page and only run tests in trusted clones with normal dev permissions.
SKILL.md
READMESKILL.md - Unit Tests
# Running Unit Tests ## Preferred: Use the `runTests` tool If the `runTests` tool is available, **prefer it** over running shell commands. It provides structured output with detailed pass/fail information and supports filtering by file and test name. - Pass absolute paths to test files via the `files` parameter. - Pass test names via the `testNames` parameter to filter which tests run. - Set `mode="coverage"` to collect coverage. Example (conceptual): run tests in `src/vs/editor/test/common/model.test.ts` with test name filter `"should split lines"`. ## Fallback: Shell scripts When the `runTests` tool is not available (e.g. in CLI environments), use the platform-appropriate script from the repo root: - **macOS / Linux:** `./scripts/test.sh [options]` - **Windows:** `.\scripts\test.bat [options]` These scripts download Electron if needed and launch the Mocha test runner. ### Commonly used options #### Bare file paths - Run tests from specific files Pass source file paths directly as positional arguments. The test runner automatically treats bare `.ts`/`.js` positional arguments as `--run` values. ```bash ./scripts/test.sh src/vs/editor/test/common/model.test.ts ``` ```bat .\scripts\test.bat src\vs\editor\test\common\model.test.ts ``` Multiple files: ```bash ./scripts/test.sh src/vs/editor/test/common/model.test.ts src/vs/editor/test/common/range.test.ts ``` #### `--run <file>` - Run tests from a specific file (explicit form) Accepts a **source file path** (starting with `src/`). The runner strips the `src/` prefix and the `.ts`/`.js` extension automatically to resolve the compiled module. ```bash ./scripts/test.sh --run src/vs/editor/test/common/model.test.ts ``` Multiple files can be specified by repeating `--run`: ```bash ./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --run src/vs/editor/test/common/range.test.ts ``` #### `--grep <pattern>` (aliases: `-g`, `-f`) - Filter tests by name Runs only tests whose full title matches the pattern (passed to Mocha's `--grep`). ```bash ./scripts/test.sh --grep "should split lines" ``` Combine with `--run` to filter tests within a specific file: ```bash ./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --grep "should split lines" ``` #### `--runGlob <pattern>` (aliases: `--glob`, `--runGrep`) - Run tests matching a glob Runs all test files matching a glob pattern against the compiled output directory. Useful for running all tests under a feature area. ```bash ./scripts/test.sh --runGlob "**/editor/test/**/*.test.js" ``` Note: the glob runs against compiled `.js` files in the output directory, not source `.ts` files. #### `--coverage` - Generate a coverage report ```bash ./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --coverage ``` #### `--timeout <ms>` - Set test timeout Override the default Mocha timeout for long-running tests. ```bash ./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --timeout 10000 ``` ### Integration tests Integration tests (files ending in `.integrationTest.ts` or located in `extensions/`) are **not run** by `scripts/test.sh`. Use `scripts/test-integration.sh` (or `scripts/test-integration.bat`) instead. See the `integration-tests` skill for details. ### Compilation requirement Tests run against compiled JavaScript output. Ensure the `VS Code - Build` watch task is running or that compilation has completed before running tests. Test failures caused by stale output are a common pitfall.