Best way for a test to reference which function it is testing?

[JustinGrote]

So I've been playing with the new vscode proposed test api, and one neat thing about their markdown example is that the tests can get a codelens right next to the actual code, not just where the test exists, which is nice not having to bounce back and forth, especially when using the autorun.

This got me thinking, maybe there should be a way for a test to reference what function it is testing (which would be completely optional). As a simple test I just used the describe block to match to the function name using an AST parser.

Should there maybe be an explicit parameter for describe/function/it blocks (e.g. "-For" to reference it is for a particular function) to codify this? It would just be an additional property on the block objects, nothing that pester would initially use directly except maybe to say Invoke-Pester -For 'Get-MyFunction').

@nohwnd thoughts?

[JustinGrote]

Related, if it was possible to get test results emitted as they complete as output objects I could make the test runner more responsive by updating the UI as the tests complete rather than waiting till the end. I suppose I could grok the text output but having a structured method would be much better. A pesterconfig output option that would be something like "objectsonly" that would return individual test objects as they complete and then the full output at the end.

[JustinGrote]

Right, I'm talking about the new proposed native interface. It operates a bit different and has some more flexibility yes.

If I just do a stream exec of pwsh instead of using Powershell Editor services then the json should get emitted to stdout as they output, so it should allow for real time updates.

[nohwnd]

Then you just need to solve the problem of mapping the object from run to the one from discovery. TylerLeonhardt/vscode-pester-test-adapter#30 (comment)

[JustinGrote]

I should be able to reasonably do this now with the NoRunoption shouldn't I? Doesn't NoRun "expand" the tests to the same object and description as they would be if it was actually run, including foreach/testcase runs?

[fflaten]

SkipRun will give you the right amount of test-obects, but ExpandedName + ExpandedPath aren't expanded until run-phase which is skipped so they will still include stuff like "<varName>". AFAIK there's no reliable unique identitfier for parameterized tests except their index/placement in the blocks.

[nohwnd]

Yup that's right. There is no link. It is a problem if tests are generated from changing data (say the number of seconds right now, to make a simple example).

TylerLeonhardt/vscode-pester-test-adapter#13 (comment)

[nohwnd]

There is long time proposal from Gael to have metadata on tests. I recommended he tries using single item -ForEach. There you can specify any data, even data you don't use in your test. He told me that he will try it, but got no feedback. All these data are then on .Data on the result object. So I would recommend you start with that as well, before we try adding something like .Metadata.

[gaelcolas]

So I did look at -Foreach and it works well for my use case.
It's a bit too loosely typed for my exact need, so I need to wrap around and provide more options.

I'm interested in the output "plugin" you speak of and how to author one, but that's probably for later. I'll keep digging.