* ci: add Node.js diagnostic reports for test crash investigation
Enable Node.js diagnostic reporting for the node.js unit test runner
so that native crashes (like the zlib crash in build 447204) produce
actionable diagnostic reports instead of a silent exit code 1.
Changes:
- Configure process.report in test/unit/node/index.js to write JSON
diagnostic reports to .build/crashes on fatal errors and uncaught
exceptions
- Add unhandledRejection handler (was missing, unlike Electron tests)
- Set NODE_OPTIONS in CI pipeline steps (win32, linux, darwin) with
--report-on-fatalerror and --report-uncaught-exception flags
- Reports are picked up by the existing crash-dump artifact collection
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* Potential fix for pull request finding
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* fix: remove process.exit(1) from exception handlers
The uncaughtException handler intentionally does NOT exit — it logs
the error and lets Mocha continue running. The test suite has a
dedicated 'Errors' suite that asserts on collected unexpected errors
at the end. Calling process.exit(1) kills the test runner on the
first uncaught exception, failing all Electron tests on all platforms.
Keep the writeReport() calls for diagnostic purposes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix: remove writeReport() from exception handlers
The manual writeReport() calls fire on benign unhandled rejections
(e.g. Canceled errors during test teardown in UserDataSyncService)
and block the event loop writing JSON reports to disk, causing
subsequent faked-timer tests to exceed their 2000ms timeout.
Report generation is already handled by process.report config and
NODE_OPTIONS flags (--report-on-fatalerror, --report-uncaught-exception)
which only fire on actual fatal errors, not on every caught rejection.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
- Som more tweaks to our own runner scripts to allow asking for the
generated coverage formats.
- Add actions alongside debug/run for executing coverage profiles
- Finish with displaying function coverage stats in Coverage view,
allow changing its sort order.
Fixes#200529Fixes#199380
- Allow coverage bar color thresholds to be configurable as the Java
folks requested.
- Update some of our scripts for integration into
the selfhost test runner.
- Initial parts of showing function coverage in the Test Coverage view.
(Still a work in progress, more tomorrow)
This adds an `assertHeap` function that can be used in tests. It
takes a heap snapshot, and asserts the state of classes in memory. This
works in Node and the Electron sandbox, but is a no-op in the browser.
Snapshots are process asynchronously and will report failures at the end
of the suite.
This method should be used sparingly (e.g. once at the end of a suite to
ensure nothing leaked before), as gathering a heap snapshot is fairly
slow, at least until V8 11.5.130 (https://v8.dev/blog/speeding-up-v8-heap-snapshots).
When used, the function will ensure the test has a minimum timeout
duration of 20s to avoid immediate failures.
It takes options containing a mapping of class names, and assertion functions
to run on the number of retained instances of that class. For example:
```ts
assertSnapshot({
classes: {
ShouldNeverLeak: count => assert.strictEqual(count, 0),
SomeSingleton: count => assert(count <= 1),
}
});
```
Closes https://github.com/microsoft/vscode/issues/191920
* eng: add support for snapshot tests
This adds Jest-like support for snapshot testing.
Developers can do something like:
```js
await assertSnapshot(myComplexObject)
```
The first time this is run, the snapshot expectation file is written
to a `__snapshots__` directory beside the test file. Subsequent runs
will compare the object to the snapshot, and fail if it doesn't match.
You can see an example of this in the test for snapshots themselves!
After a successful run, any unused snapshots are cleaned up. On a failed
run, a gitignored `.actual` snapshot file is created beside the
snapshot for easy processing and inspection.
Shortly I will do some integration with the selfhost test extension to
allow developers to easily update snapshots from the vscode UI.
For #189680
cc @ulugbekna @hediet
* fix async stacktraces getting clobbered
* random fixes
* comment out leak detector, for now
* add option to snapshot file extension
* tests - run unit tests also against node.js
* fixes
* fail if major node.js version mismatch
* -tfs is unsupported
* Add `@ts-check` and remove `jsdom`
* tests - process.env layer breaker
* Improve loader config
* skip one test
* address todos
* try to force color output
* Use a file: URI as baseUrl
Co-authored-by: Alex Dima <alexdima@microsoft.com>
Alexandru Dima
Osvaldo Ortega
Benjamin Pasero
João Moreno
Johannes
Connor Peet
João Moreno
Robo
Raymond Zhao
Alexandru Dima
Benjamin Pasero