Provide machine-friendly, streaming output format

[davidmatson]

Checklist

• Feature request has a meaningful title
• I have searched the existing issues. See all issues
• I have tested using the latest version of Pester. See Installation and update guide.

Summary of the feature request

Our ES testing infrastructure has its own reporting mechanism, and we've previously integrated with many other test frameworks, including GoogleTest, Catch2, Boost.Test, VSTest / xUnit.Net / NUnit / MSTest. Most of these frameworks provide a built-in output format that is streamed (provides the data as the tests are running) as well as programmatically-processible (XML written to stdout for Catch2 and Boost.Test, URL-like lines written to a socket for GoogleTest). Could Pester provide such an output format as well?

This would provide a mechanism that could be used to adapt Pester test results to any other format, while the Pester tests are running. Runners such as VS Code might also make use of this format as a stable way of presenting results, rather than needing the currently-non-public add-in mechanism.

How should it work?

Invoke-Pester (or the configuration object) provides a way to specify that the output mode is machine-friendly (rather than the default of human-friendly). Perhaps a new Output.Mode on PesterConfiguration, with values of 'Human' (default) and 'Machine' (new), with machine output looking something like this (inspired by the GoogleTest machine-friendly output format):

pester_streaming_protocol_version=1.0
event=PesterStart&version=6.0.0
event=DiscoveryStart
event=Discovered&path=C:\t\Planets\Get-Planet.Tests.ps1
event=DiscoveryEnd
event=RunStart&path=C:\t\Planets\Get-Planet.Tests.ps1
event=DescribeStart&name=Get-Planet
event=ItStart&name=Given%20no%20parameters,%20it%20lists%20all%208%20planets
event=ItEnd&result=fail&duration=40ms&message=The%20term...&file=C:\t\Planets\Get-Planet.Tests.ps1&line=7
event=DescribeEnd
event=RunEnd

[davidmatson]

Other options that could work for the same scenario:

XML to stdout:
Parsing streaming XML (no DOM, as the file isn't fully written yet) is harder than the format above, but Catch2 and Boost.Test use this mechanism, and it could work.

Add-in:
This requires getting the caller involved more in the execution environment than passing a switch and consuming a programmatic format from stdout. We had to use this approach for VSTest, and it was much less flexible for execution environment integration.

[davidmatson]

Related to #550 and #447 - this might work for both of those cases as well as others.

[davidmatson]

@nohwnd - thoughts on this feature? We'd be interested in working on an implementation draft, if there's agreement that this would be a good idea.

[nohwnd]

I can't promise anything right now, I work on v6 when I can, and my time is limited.

This does not look like a feature that would be usable to everyone. Do you see some uses for this that would allow us to support some new exciting thing, rather than just your own reporting mechanism? e.g better ide integration in vscode.

[fflaten]

Also related to #2021 so you could add or replace with custom output.

[davidmatson]

@nohwnd - yes, I'd imagine VSCode integration could use this rather than the currently-unsupported hook that it's currently using to show progress in the IDE as tests are executing. Thoughts?