Anchor module-less Mock to the test scope instead of the caller's module#2821
Open
nohwnd wants to merge 1 commit into
Open
Anchor module-less Mock to the test scope instead of the caller's module#2821nohwnd wants to merge 1 commit into
nohwnd wants to merge 1 commit into
Conversation
When Mock or Should -Invoke is called without -ModuleName from a helper function that lives in a module (for example a reusable mock-injection helper), the mock was silently scoped to that helper module instead of the test scope, so it never applied to the command under test. Resolve the target session state explicitly: keep inheriting the module only for intentional in-module calls (inside InModuleScope, or when the current block/test body was itself defined in that module), and otherwise anchor the mock to the test/script session state. InModuleScope now marks the module it is executing in so these calls are recognised, and Mock and Should -Invoke share the same resolution so they stay consistent. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
|
needs careful review |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix #2025
Problem
When
Mock(orShould -Invoke) is called without-ModuleNamefrom a helper function that lives in a module — for example a reusable mock-injection helper — the mock was silently scoped to that helper module instead of the test scope. As a result the mock never applied to the command under test, and the real command ran instead.The root cause is that the target was inferred purely from the caller's session state module: any call originating inside a module inherited that module, with no way to tell an intentional in-module mock (
InModuleScope M { Mock ... }) from one that merely passes through a module-defined helper.Fix
Resolve the mock target explicitly via a shared
Resolve-MockCallerScopehelper used by bothMockandShould -Invoke, so they always agree on where the mock lives:InModuleScope <module> { ... }(InModuleScope now pushes/pops a marker for the module it runs in), orInModuleScopewrapping aDescribe).Mockin the test would.Tests
Describeintst/functions/Mock.Tests.ps1covering the helper-injected mock applying to the test,Should -Invokeconsistency from both the helper module and the test scope, and a boundary check thatInModuleScopewithout-ModuleNamestill targets the module. These were verified to fail on the unpatched build and pass with the fix.InPesterModuleScopecases take the block-match path and are preserved).Validation
Full suite green — P-tests pass plus 2496 Pester tests, 0 failed. Mock.Tests.ps1 (254) and InModuleScope.Tests.ps1 (39) all pass. Build analyzer reports no new violations in the edited source files.