Ability to specify the path to the location of the actual problem in the test result
Glober777 opened this issue · comments
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
I've got some dynamic tests (builds up a list of items during the Discovery phase and uses it as Test Cases) that are supposed to automatically apply to all the script files in my project folder (i.e. Help test, Syntax, etc.). Generally, all works great, however, when a test case fails (i.e. there's a problem with a help article or, say, there's a syntax error discovered by the test), the error record contains a path pointing to the place where the test is defined. While such a behavior makes perfect sense in many cases (in most of them, probably), I'd really like to be able to override that (or populate a dedicated attribute, if such exists) with a path to the file containing a script with missing/broken help article or to a syntax problem. That would allow making the test results even more meaningful as well as make the tools that rely on that information (i.e. Pester Tests extension in VSCode) more useful.
So far I wasn't able to find a way to do that in Pester 5. Given that Assertions are now being migrated into Pester with v6, I thought that maybe this can become as a nice to have feature request for version 6 as well?
How should it work?
For example this could be implemented with some new Assertion cmdlet (i.e. Assert-TestFailure) that would have parameters that would accept the path to the script, line number and, maybe, some text that can be used as a error message (description).
That is interesting idea, I am not sure how well we could mesh it with the internal code that processes stack trace, or how useful this approach would be to users that are not you. But let's keep it here to collect upvotes.
As a workaround you could use the -Because parameter to provide the path to file, if you provide it in the format that pester stack report uses it will be clickable in vscode and you can navigate directly to the file, just as with stack trace (they are both just text printed to the screen that vscode parses).
As a workaround you could use the -Because parameter to provide the path to file, if you provide it in the format that pester stack report uses it will be clickable in vscode and you can navigate directly to the file, just as with stack trace (they are both just text printed to the screen that vscode parses).
Now that's an awesome workaround! Thank you for suggestion.