VS Code Unit Test Runner
Run VS Code repository unit tests by file, test name, or compiled-output glob.
The skill only directs test execution, requests no credentials or secrets, and distinguishes a preferred tool from local script fallbacks; however, it does not explain Electron downloads, network dependencies, user confirmation, data flow, rollback, or isolation, so points are deducted.
The instructions are internally consistent and cover runTests, macOS/Linux and Windows scripts, filtering, coverage, timeouts, and the compilation prerequisite; however, there is no executable reproduction, compatibility matrix, or diagnostic handling for abnormal arguments and download failures. Under static calibration, the score is capped at 10.
The audience and main inputs are reasonably clear, including tool-versus-CLI fallback, platform differences, and the unit/integration-test boundary; however, runTests availability, additional non-fit cases, output format, Chinese-language support, and operation under restricted networks are not specified.
The YAML metadata, progressive sections, command examples, aliases, and common pitfall note are clear, while the repository supplies an MIT license, version, and official maintenance context; however, the skill itself lacks maintainer ownership, update path, changelog, dependency-installation notes, and FAQs, warranting only a mid-range score.
The skill can directly help users select a runner or script and construct common commands, covering files, names, globs, coverage, and timeouts; however, examples are conceptual rather than verified outputs, and result format, failure handling, and comparative benefit over manual execution are not established. Static calibration caps this at 7.
The commands, parameters, and compilation prerequisite are somewhat auditable, and the repository includes tests and CI material; however, the supplied workflows do not directly cover this unit-test skill, with no evidence covering runTests or scripts/test.sh key paths and no third-party reproduction. Static calibration caps this at 5.
- Test execution may download Electron and depend on network access; no mirror, cache, or offline procedure is documented for restricted or mainland-China network environments.
- The runTests interface has no checkable availability guidance, output example, or failure diagnostics; the conceptual example does not verify actual parameter behavior.
- Compilation or a running watch task is required, but the skill does not explain how to verify fresh build output or handle download, compilation, and test failures.
What does this skill do, and when should you use it?
This skill is for running unit tests in the microsoft/vscode repository. It prefers the runTests tool when available because it provides structured pass/fail details, and otherwise uses the platform-specific repository scripts. It supports filtering by test file, test name, and glob, as well as coverage and timeout options. Tests run against compiled JavaScript output, while integration tests are outside the scope of scripts/test.sh and scripts/test.bat.
It first uses the runTests tool with absolute test-file paths, test-name filters, or coverage mode. When that tool is unavailable, it runs ./scripts/test.sh on macOS/Linux or .\scripts\test.bat on Windows. The skill can select files with positional paths or --run, filter full test titles with --grep, -g, or -f, match compiled .js files with --runGlob, --glob, or --runGrep, enable --coverage, and set --timeout. The scripts download Electron when needed and launch the Mocha test runner.
- A VS Code developer wants to verify one editor-model test file and runs only that source file.
- A developer is investigating one test title and combines --run with --grep to narrow execution.
- A feature-area maintainer wants to run all compiled test files matching a glob and uses --runGlob.
- A developer needs a coverage report and adds --coverage to the target test command.
- A long-running test requires a different Mocha timeout and uses --timeout.
- A developer working on integration tests switches to scripts/test-integration.sh or scripts/test-integration.bat instead of the unit-test scripts.
What are this skill's strengths and limitations?
- Covers the runTests tool plus separate macOS/Linux and Windows script workflows.
- Supports narrowing execution by file, test title, or compiled-output glob.
- Includes documented coverage and timeout options.
- The repository source is licensed under MIT.
- There is no evidence of a standalone installation process or separate package.
- Tests require current compiled JavaScript output; stale output can cause failures.
- The documented unit-test scripts do not run integration tests, which require other scripts or skills.
- The source does not identify which clients provide runTests or show a sample structured report.
How do you install this skill?
The skill is located at .github/skills/unit-tests/SKILL.md in the microsoft/vscode repository. The source does not provide a standalone installation command or separate package; obtain the repository and configure an Agent Skills-compatible client to load this file. The repository README says the collection contains 61 skills and that its source code is licensed under MIT, but this profile covers only unit-tests.
How do you use this skill?
In an obtained VS Code repository, ask for something such as “Run the unit test named should split lines in src/vs/editor/test/common/model.test.ts.” If runTests is available, use it with the file and test-name filters; otherwise run ./scripts/test.sh --run src/vs/editor/test/common/model.test.ts --grep "should split lines" from the repository root. On Windows, use .\scripts\test.bat --run src\vs\editor\test\common\model.test.ts --grep "should split lines". Before running, ensure the VS Code - Build watch task is active or compilation has completed.