Guidance Request: Best way to create an output.ps1 plugin that emits Test objects to Write-Output in real time

[JustinGrote]

@nohwnd @fflaten I may need a little guidance on what is the best way to emit the Test objects found in the .Tests property of the passthru result via the output.ps1 you mentioned

I just need the tests as they complete to be output pipeline style, not all at the end, so I can update the test API as the tests are completed rather than just at the end, and I'd rather not try to parse the Write-Host output if at all possible.

So end result when I run invoke-pester would be:

1. Write to host all the stuff it normally does at the verbosity level it does
2. Rather than output everything at the end with -Passthru, output [Test] objects right after every time it writes the write-host of the test result. The [test] objects should be fully formed ideally, including all the test result metadata and the parent block.

[JustinGrote]

I think this is where I am looking:

Pester/src/functions/Output.ps1

Lines 649 to 650 in 8fb1317

	$result = $_test.Result
	switch ($result) {

Basically I want an option that, at this point, to just do $_test | Write-Output in addition to going through the switch and doing the write-host output, not sure the best way to go about that though, I assume it's going to require a PR to pester directly or is there a way with this "output plugin" method you speak of to do it without a PR?

EDIT: I tried putting a write-output here directly and it never came out, I assume it's getting swallowed upstream.

[JustinGrote]

So I think I need to make something that can go to new-pluginobject that looks something like this?

$p = @{Name='OutputToPipe'}
$p.EachTestTeardownEnd = {param($context) #Write $context.Test to the named pipe}

Registering a new plugin won't clobber the other one right? So write screen will still happen? This seems like the best way. How would I then go about registering the plugin? Do I have to run everything within the pester module scope with & (gmo pester)?

[nohwnd]

Plugins are not public, so yes. Your only option is to add a plugin by running code in the module. A small problem is that plugins are figured out in Invoke-Pester (e.g. write screen is not registered at all when you specify -output None), and there is no good extension point for adding external plugins because when we reach user code where you could manipulate the state of plugins, there were already few steps run. (Plugin Step is e.g. EachTestTeardownEnd )

But for start it still might work for you if you manipulate the plugins in discovery, because you only need a step that is part of Run. We can work on making the plugins system public, but I don't see that happen until at least 5.4.

[JustinGrote]

@nohwnd so it looks like my best backwards-compatible way in is to override the Get-WriteScreenPlugin function with a proxy command that runs its logic and then shims in my own plugin object, that seems to be working fine and will be my go-forward for now.

To make this easier, how about just defining a variable at module scope ($script:AdditionalPlugins) and just bring that in via $plugins += $AdditionalPlugins? Thats a two line non-breaking change and allows someone so inclined to inject plugins pretty easily into the module at module scope without having to expose a whole "public" plugin API.

[JustinGrote]

I made a PR: #2020

[JustinGrote]

Here is my injector in the meantime

ipmo pester
& (gmo pester) {
    if ($SCRIPT:GetWriteScreenPlugin) {return}
    [ScriptBlock]$SCRIPT:GetWriteScreenPlugin = (Get-Item 'Function:\Get-WriteScreenPlugin').ScriptBlock
    function SCRIPT:Get-WriteScreenPlugin ($Verbosity) {
        . $SCRIPT:GetWriteScreenPlugin -Verbosity $Verbosity
        $newPluginParams = @{
            Name = 'NamedPipeOutputPlugin'
            EachTestTearDownEnd = {
                param ($Context)
                $testItem = $Context.Test
                Write-Host -Fore Magenta "RAN TEST: $($testItem.ExpandedPath)"
            }
        }
        New-PluginObject @newPluginParams
    }
}

invoke-pester C:\Users\JGrote\Projects\vscode-adapter\sample\Tests\Basic.Tests.ps1