-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Should vscode-jest-runner migrate into the #312
Comments
when the extension was created there was no test ui and no test api. i think there are potential upsides and downsides. with our solution we are super flexible because we dont use their API, we also dont need to migrate from Test-Adapter to Native Test API. on ther other side the offical native test api would probably be more clean, less hacky and probably better visual capabilities for displaying test-results. |
Looks like @rossknudsen is working on bringing the current Jest Test Adapter extension up to date – maybe better to double down on that one and keeping this a separate one? https://github.com/kavod-io/vscode-jest-test-adapter/tree/feature/152-native-tests |
I was going to do that. But realised that vscode-jest does everything that vscode-jest-test-adapter does with the integration into the native test explorer. I was going to deprecate and archive it. |
Problem
VSCode has a native testing UI that is always rendered, present in addition to this extension's test decorations, yielding a potentially confusing duality of how to run IDE-triggered test executions.
VSCode native testing prompt: The left arrow
vscode-jest-runner: the top "links"
Discussion
VSCode has a formal API to bake test executions and results in: https://code.visualstudio.com/api/extension-guides/testing
Let's enumerate reasons why we should/should not migrate to use the VSCode APIs directly.
The text was updated successfully, but these errors were encountered: