-
Notifications
You must be signed in to change notification settings - Fork 29.3k
Writing Tests
VS Code has several types of tests:
- Unit tests that run against VS Code itself
- Integration Tests that test more real-world scenarios
- Extension Tests that run against built-in extensions
- Smoke Tests that test end-to-end in a real editor
Unit tests are the files in src/vs/**/*.test.ts
. Depending on the layering, a test may run in...
- Browsers (in
common
orbrowser
), - Electron (in
common
,browser
, orelectron-sandbox
), - or Node.js (in
common
ornode
)
Tests can be run manually on the command line, see the instructions here. They can also be run from the VS Code UI using the Selfhost Test Provider.
Infrastructure
Unit tests are written using Mocha's BDD interface. We use the sinon
library for mocks, and the assert
module for making assertions.
When using Sinon, you should make sure to call sinon.restore()
in your teardown
block to avoid leaking memory
Ensuring Clean Teardown
When writing new tests or updating old ones, you should use the ensureNoDisposablesAreLeakedInTestSuite()
helper function in your test suite to make sure code is torn down cleanly. This can find bugs both in tests as well as the code you're testing. Use it like so:
suite('myCoolTests', () => {
setup(() => { /* ... */ });
teardown(() => { /* ... */ });
ensureNoDisposablesAreLeakedInTestSuite();
});
Snapshot Testing
Aside from that, we also support Jest-like snapshot tests using the assertSnapshot
helper. Here's an example.
The first time you run a snapshot-containing test, the snapshot will be written to the `snapshots`` directory beside the test file. Look at the output file and verify that it's sensible with what you expected. On subsequent runs, the output will be compared to the snapshot file, and differences will fail the test.
The layout and authoring of integration tests is identical to Unit Tests, but their files are suffixed with .integrationTest.ts
instead of .test.ts
. Tests that use real external APIs that are more prone to slowness or failure should be written as integration tests.
They are supported by the Selfhost Test Provider, and can be run from the CLI can be executed using ./scripts/test-integration
or by manually running ./scripts/test.sh --runGlob **/*.integrationTest.js
.
Extension tests are written using the standard, public extension testing system. They are not supported by the selfhost test provider yet. They can be executed using ./scripts/test-integration
, or by running the launch configs found in individual extensions' folders.
Project Management
- Roadmap
- Iteration Plans
- Development Process
- Issue Tracking
- Build Champion
- Release Process
- Running the Endgame
- Related Projects
Contributing
- How to Contribute
- Submitting Bugs and Suggestions
- Feedback Channels
- Source Code Organization
- Coding Guidelines
- Testing
- Dealing with Test Flakiness
- Contributor License Agreement
- Extension API Guidelines
- Accessibility Guidelines
Documentation