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.
I recently ran into an issue where I was trying to call showQuickPick with a readonly array. This is currently not allowed, even though `showQuickPick` never mutates the input
This change marks a few places in `vscode.d.ts` where we take arrays as parameters as `readonly []`. It also caught a potential bug with`getSession` modifying the input array
* Simplify logic for webview resource uris
This change attempts to simplify the logic around webview resource uris by doing the following:
- Hard code the resource origin. We always will be hitting a service worker for these paths so they don't need to be dynamic (although in the future we may want to pull them from `product.json`)
This lets us remove these properties from the environment service
- Move remote handling from the resource loader in `asWebviewUri`.
- Remove the handling of http and https paths from the resource loader.
I don't think these cases can be hit any longer (although I need to confirm this with more testing for the web case). Instead I added a check to `asWebviewUri` so that we return the original uri if a http(s) uri is passed in
* Restore normalizeResourcePath
We still need to convert between a remote uri and one that our remote file system can read
* Fix test
* Restore passing in remote on extension side
* Remove only
