Closed Splaxi closed 2 years ago
Thanks for the report. ExpandedName
and ExpandedPath
are evaluated after the setups because they could create variables used in the name iirc. So skipping inside BeforeEach
vs It
will be different since the latter will already be finished with setups -> name is expanded.
We could however update the placeholder-value for ExpandedPath
that you see now to be expanded as far as we reached before skip/failure. That would solve the sample in this issue where only the block has a variable + make it easier to identify the correct block in general. š
Thanks for the feedback.
Is there any way I can assist with this, so we can have the change to be part of the next release? I'm new to the code base of pester, but I'm up for the challenge to see if I can fix it and do the PR.
Just need some pointers, then I can test local and see if my scenario can be handled or not.
Absolutely, contributions are always welcome š You can see how to build and test in CONTRIBUTING.md. I personally use the devcontainer in the repo so I don't need .NET locally.
As for the code:
Test (It)
You can see how ExpandedPath
is set here. I'm thinking we could set it once more earlier in Invoke-TestItem
before the skip-check and/or framework-setup. $Test
should be the same as CurrentTest
at that point.
Block (Describe/Context)
Current logic is here. ExpandedPath
could be set the same way probably around L321.
We should also add a test or two similar to this to verify that it works when a) a block fails due to BeforeAll
, b) a test with -Skip
or that fails (or Set-ItResult
which is a special exception) in BeforeEach
. These are P-test which are used to test behavior of Pester-engine itself from the outside. b
is like describe/context
, i
is like it
and we can only use the Verify-*
assertions found in the tst\axiom
-folder.
Still interested in submitting a PR @Splaxi? š
Yeah - but when I tried the last time, I couldn't find a way to solve the issue.
So I feel that I'm smart enough to tackle the challenge, regardless of me having the issue š¤¦āāļø
Looking back at it months later - it wasn't my best explanation š I think I've covered it in the related PR.
Checklist
What is the issue?
It seems that the logic with expanding the path of a given test, is being handled differently when we are talking about the detailed output and the output object.
The detailed output expands the path of each test / describe:
But the output object looks like this:
Expected Behavior
I would expect the expanded path to work the same way as the detailed output, so when you are generating NUnit/JUnit files, the would reflect the same values.
Steps To Reproduce
No response
Describe your environment
No response
Possible Solution?
No response