Replies: 5 comments 5 replies
-
I don't know if this will even be technically feasible, but it seems like it would make global side effects easier to grasp for people who need them in order to generate tests. I will keep digging into this to see if that change is warranted. |
Beta Was this translation helpful? Give feedback.
-
#1885 (comment) This describes the module issue in more detail. |
Beta Was this translation helpful? Give feedback.
-
This describes the need for global setup: #1645 (comment) |
Beta Was this translation helpful? Give feedback.
-
Sounds interesting, a middle ground between Pester 4 and 5. Feels more streamlined for any future parallelization support. Run would feel slower though so we'd have to include discovery time in the container output to explain the repeating pauses. Never used to Focus-mode so maybe I'm missing something. Why would this block Focus? Wasn't that always a switch parameter put on tests, which means at least parts of discovery had to run on all containers to look for it? Wouldn't a tag be just as quick? |
Beta Was this translation helpful? Give feedback.
-
That is maybe true, a file that is not well behaved can take few seconds to discover. But the same would be true for the discovery happening at the start, and is probably even worse because there all the "delays" add up into one big pause. Normally files are discovered in couple of milliseconds, which I am not sure if the user would even notice. |
Beta Was this translation helpful? Give feedback.
-
I am thinking about moving discovery and run closer together: Instead of Discovery, Discovery, Discovery, Run, Run, Run, it would do Discovery, Run, Discovery, Run, Discovery, Run, on file by file basis.
This should help with global side effects:
What we lose:
-Focus
functionality that runs only focused tests when there is at least 1 focused test, no matter how many files are provided. This is a nifty little feature, but can be largerly replaced by adding "breakpoint" like functionality for tests in VSCode extension, or by code lens that we already have - both of those features would use the line filter that is built into Pester. Using code edits to narrow down the run is also inferior to a GUI approach, because a gui approach is impossible to accidentally commit into codebase, which end up running just a single test in CI. Which is why I hiddent that -Focus functionality from Pester5 release.Beta Was this translation helpful? Give feedback.
All reactions