search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
164.06k stars 29.24k forks source link

Consider a "test-adapter-protocol" that maps onto the new testing APIs #134455

Open DanTup opened 3 years ago

DanTup commented 3 years ago

I'm a big fan of common protocols like LSP + DAP that reduce the effort for a new language/editor to have support for other editors/languages and have recently been working on implementations for Dart.

While migrating to the new VS Code test runner recently, I was wondering if something similar could be done for these new testing APIs. Rather than implementing it directly inside the VS Code extension in typescript, if it could be pushed off to another process it could have some of the same benefits as LSP/DAP (eg. other editors may adopt it, tools can write more code in their native languages, etc.).

For Dart, all of the test runs go through the DAP, so the DA is currently forwarding custom JSON events from the package:test runner to the extension, and then the extension is translating them into VS Code API calls. It would be much nicer if I could do that translation inside the DA and then other editors could potentially share it.

Even as a completely separate protocol, I could forward the events from the DAP straight onto the test protocol client - the useful part is doing the translation in the DAP into a standard protocol that may gain traction like LSP/DAP have.

@isidorn @weinand @jacob314

weinand commented 3 years ago

@connor4312 what's your opinion about this?

connor4312 commented 3 years ago

I like this idea. The testing APIs are an easy API for extension authors to use, and in forging them we created a good model of the domain we wish to model. We can now give it a similar treatment as we did for LSP. I will bring this up with Kai this week and discuss scheduling.