Data was viral and spread generics all over the place. It was also
hard to type correctly and consistently, which ended up in the type
being `any` unless great care was taken.
This removes the `data`. Instead, consumers can use a `WeakMap<TestItem, T>`
to keep data associated with the test item. This is a similar pattern
to what is used to store data about documents and debug sessions, for
example. Here's an example of a migration:
8fdf822985 (diff-2fe3ad6ad19447c57c5db14c5a6ccb5544944494db6b909540d70ea499784b49R9)
Previously in the testing API, you called `registerTestProvider` with
your own instance of a TestController, and VS Code would request
workspace or document tests. This has been changed: now, you call
`createTestController`, which returns an object, and call
`createTestItem` to insert test nodes under the `controller.root`.
Extensions should generally decide themselves when to publish tests. For
example, when a file is opened in an editor, test extensions will want
to make sure tests for that file are available so that inline
decorations can be shown. This is pretty similar to what the editor
API does in diagnostics.
There is still a `resolveChildrenHandler` on the controller (rather than
the TestItem directly), which you should _set_ if the test extension
supports lazy discovery. Additionally, if you support running tests,
you'll also want a `runHandler` (migrating from the old `runTests` method).
Some of the existing test providers have been updated, you can check
them out here:
- https://github.com/microsoft/vscode-extension-samples/tree/main/test-provider-sample
- https://github.com/microsoft/vscode-selfhost-test-provider
In summary, to update to the new API:
- Call `vscode.test.createTestController` instead of `registerTestController`
- Move the contents of your `runTests` method to `controller.runHandler`
- Move your `TestItem.resolveHandler` to `controller.resolveChildrenHandler`,
which may involve adding some `instanceof` checks.
- If you lazily discovered tests in `createDocumentTestRoot`, you'll want
to trigger that logic based on `vscode.workspace.onDidOpenTextDocument`.
- If your test runner can deal with showing locations of unsaved changes,
listen for `vscode.workspace.onDidChangeTextDocument` to trigger those
changes in the tree.
For #120675
This uses a script to add the override keyword to places that need it in the codebase
Note that we can't enable the --noImplicitOverride setting yet since there are still around 200 errors that require further attention
Fixes: https://github.com/microsoft/vscode/issues/115101.
See issue for details.
- Adopts the new API
- Test results now persist across reloads (last 64 runs).
- Removed state grouping in favor of sorting option.
- Code lenses are disabled for now
The WorkspaceTestCollectionService duplicated collection logic
unnecessarily. Centralize to the TestService's collection.
This also moves the state updates for discovering tests, and a new
update for adding roots, into the diff, which lets us synchronize those
changes with the changes to test collections.
There's a super crazy bug with the "run all" action that I have
not dove into yet.
