Open cdaringe opened 1 year ago
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. maybe this flexablity comes in handy for many users.
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
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.