Write access
Closed this issue · 10 comments
We've not got the test API in a shape where we're ready to start carrying forward to finalization next month. It's evolved quite a bit since you initially wrote this adapter. I'd like to update it (particularly so we can start self-hosting the mocha runner microsoft/vscode#120388) and continue updating it as any final tweaks go in. Could you do two things to let me do so?
- Add a (preferably MIT) license
- Add me as a contributor on the repo
Thank again for your work on this, and your work building an ecosystem around testing in VS Code! 🙂
I ended up writing a mostly fresh version here: https://github.com/microsoft/vscode-test-adapter-converter. The API changed pretty heavily since this was first written
Nice, I'll play with it next weekend.
What are the plans for your converter extension? I think it would be best if I integrate this into my Test Explorer extension as soon as the TestProvider API is final. Initially this would be optional and switched off by default (so that Test Explorer users and Test Adapter authors can start playing with it if they want) and when I feel that the integration works well enough, I'd make this the default (but let users switch back to the old Test Explorer UI if they see any issues). That way the Test Explorer users would be transitioned to the new UI automatically.
I think that makes sense.
I expect to start finalization on the relevant APIs next month. If you're eager to integrate, I can allowlist the Test Explorer UI to use proposed APIs so that you can have developers start playing with the toggle ahead of time. Then perhaps in late June, given the APIs are finalized, it could go on by default.
If you're eager to integrate, I can allowlist the Test Explorer UI to use proposed APIs so that you can have developers start playing with the toggle ahead of time.
I don't think that's necessary, developers can just use your converter extension for now.
Ok, sounds good. How about we define a new setting testExplorer.useNativeTesting: true/false. If that's true, then the Test Explorer UI extensions disables all its UI. I'll have the converter watch that and become active when it's true. Then if the Test Explorer UI declares the converter in its extensionDependencies, the toggle should work.
Also, the Test Explorer could fire a command like testExplorerConverter.activate before it starts loading any tests from adapters. That can let the converter activate lazily and also make sure its listeners are installed so they don't miss anything.
Gentle ping @hbenl 🙂
Ok, sounds good. How about we define a new setting testExplorer.useNativeTesting: true/false. If that's true, then the Test Explorer UI extensions disables all its UI. I'll have the converter watch that and become active when it's true. Then if the Test Explorer UI declares the converter in its extensionDependencies, the toggle should work.
Also, the Test Explorer could fire a command like testExplorerConverter.activate before it starts loading any tests from adapters. That can let the converter activate lazily and also make sure its listeners are installed so they don't miss anything.
What do you think about this approach? I can submit to PR to the Test Explorer UI extension if you think it sounds good
Yes, that sounds good. Should I add the converter as an extension dependency already (even though the new testing API isn't in vscode-stable yet)?
the Test Explorer could fire a command like testExplorerConverter.activate before it starts loading any tests from adapters
OK, I'll do that.
I can submit to PR to the Test Explorer UI extension if you think it sounds good
If you like, but I can also do it myself.
Adding the converter as a dependency sounds good. It has access to the necessary proposed APIs, which should be finalized this coming iteration.
I can put in a PR late next week if you don't get to it by then.