Provide public API to subscribe to test results.

[rossknudsen]

This PR exposes a public API from this extension which other extensions may retrieve and utilize. Currently it merely provides an object that has a subscribe method to receive updated test results. This enables other extension authors to benefit from the test results without having to run the tests themselves.

[wmertens]

Great idea IMHO - doesn't this also need some API to enumerate discovered tests and to run them?

[rossknudsen]

@wmertens yes, I totally agree. This is by no means a complete implementation. I was just testing the waters before jumping in too deep. As it is, I've written the unit tests now, so hopefully it can get the green light.

If this gets merged, then we can put together a wish list for the public API. It'd be great to see others involved too. Since it would become a public contract, it would be great not to have to change it, as maintaining backwards compatibility is a pain.

[connectdotz]

@rossknudsen can you elaborate on the use cases you are trying to address? Please be aware that vscode is also exploring a TestProvider extension API: see Testing in VS Code...

[rossknudsen]

@rossknudsen can you elaborate on the use cases you are trying to address? Please be aware that vscode is also exploring a TestProvider extension API: see Testing in VS Code...

Huh, I wish I had seen that thread the other day!... I've just skim read it now and I think it is probably worth me switching to that thread to continue the discussion. I can answer a bunch of your questions.

[rossknudsen]

@connectdotz what I'm trying to achieve is to gain synergies between this extension and the one I maintain. Here are some of the thoughts in my head:

• This extension has Sidebar support #357 to add a GUI for the test runs while the one I maintain already has one provided by Test Explorer UI.
• This extension has the run output displayed in an output window, while the one I maintain does not, but has open feature requests.
• This extension has a much higher usage and has dealt with a lot of different project setups, while I'm still trying to deal with different configuration etc.

When I discovered the other day that extensions can provide a public API that other extensions can interact with, I realised that if the test information that this extension was made available to my extension, then I would save myself a lot of headache. You might also find that you can split some of the UI related stuff in this extension into separate extensions.

Also given the thread that you linked about the direction that VS Code is heading around this, then this might be a step in the right direction.

[connectdotz]

@rossknudsen thanks for the interest. I think this is a significant direction change from the original design goal. Not that it is not doable but one that requires a much deeper discussion. Giving we are sort of short on resources (v4 has been opened for over 6 months), I am afraid that we won't have the bandwidth to consider this new direction until later, I am going to tag it for a future discussion...