* add `ListenerRefusalError` and `ListenerLeakError` which get logged when listener thresholds are exceeded.
The `stack` property of these errors will point towards the most frequent listener and how often it is used. If that's a high number there is a leak (same listener is added over and over again), if that's a low number there might be a conceptual flaw that an emitter is simply too prominent.
* rightfully don't use Error.captureStackTrace (v8/nodejs only)
- 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)
* snippet completions should also check with the completion model
this will allow to return "more" from the snippet completion item provider and rely on the completions model to do some filtering
* when debugging tests allow to use console.log
* fix https://github.com/microsoft/vscode/issues/191070
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
Second attempt at this, which should work. Stop trying to use
exposeFunction, which seems to work poorly on macOS webkit in CI, and
just run a server with HTTP endpoints to do the "RPC."
Reuses Alex's "yaserver" module that we were already using for other
tests. Uses a secure random prefix for security in each run.
Should fix the issue that @roblourens and @Yoyokrazy were hitting with snapshot tests on macOS WebKit in CI. Not pretty, but I'd rather do this than spend a bunch of time chasing down something that certainly seems to be a browser issue.
* 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
* Add more logging and perf markers around resolving the connection token and the socket factory
* set `exposeFunction` earlier
* bla windows
* also expose function for unit tests beofre opening
Co-authored-by: Benjamin Pasero <benjamin.pasero@microsoft.com>
* ipc: use vql for uint types
On the plane I was reverse-engineering ipc.ts to implement it in Rust
and see if we could have a "service mode" for the CLI that we could
interact with like any other vscode process.
In doing so, I noticed that numbers in the protocol--which are used at
least twice in the message header and ID--were encoded as JSON. I was
curious what benefits we'd get from encoding them as variable-length
integers instead.
It makes the message shorter, as expected. Encode/decode time are very,
very slightly lower. I'm not sure it's worth the extra complexity, but
I have included it here for your consideration.
* fixup tests
