Mocks of functions in nested modules fail on Invoke-Pester wildcard discovery

[tiararodney]

Checklist

• Issue 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.

What is the issue?

The following invocations work as expected:

$ pwsh -c "Invoke-Pester Contoso/NestedModule2.Tests.ps1"

Starting discovery in 1 files.
Discovery found 1 tests in 81ms.
Running tests.
[+] /Users/tr/Desktop/Contoso/Contoso/NestedModule2.Tests.ps1 311ms (123ms|120ms)
Tests completed in 317ms
Tests Passed: 1, Failed: 0, Skipped: 0 NotRun: 0

$ pwsh -c "Invoke-Pester Contoso/NestedModule3.Tests.ps1"

Starting discovery in 1 files.
Discovery found 1 tests in 85ms.
Running tests.
[+] /Users/tr/Desktop/Contoso/Contoso/NestedModule3.Tests.ps1 310ms (121ms|119ms)
Tests completed in 316ms
Tests Passed: 1, Failed: 0, Skipped: 0 NotRun: 0

However, doing this through a wildcard discovery somehow fails for 1 of the tests:

$ pwsh -c "Invoke-Pester Contoso/*.Tests.ps1"

Starting discovery in 2 files.
Discovery found 2 tests in 83ms.
Running tests.
[+] /Users/tr/Desktop/Contoso/Contoso/NestedModule2.Tests.ps1 308ms (122ms|119ms)
[-] Get-SomethingInModule2.default.does something 12ms (11ms|1ms)
 RuntimeException: should always throw
 at Get-SomethingInModule1<Process>, /Users/tr/Desktop/Contoso/Contoso/NestedModule1.psm1:9
 at Get-SomethingInModule3<Process>, /Users/tr/Desktop/Contoso/Contoso/NestedModule3.psm1:8
 at <ScriptBlock>, /Users/tr/Desktop/Contoso/Contoso/NestedModule3.Tests.ps1:22
Tests completed in 364ms
Tests Passed: 1, Failed: 1, Skipped: 0 NotRun: 0

Expected Behavior

Since I'm mocking the Get-SomethingInModule1 for each separate module scope of NestedModule2 and NestedModule3, I would expect the mocks not to interfere with each other.

Steps To Reproduce

$ git clone https://github.com/oxbqkwwxfrqccwtg/pester-container-issue-demo.git
$ cd pester-container-issue-demo

$ pwsh -c "Invoke-Pester Contoso/NestedModule3.Tests.ps1"

$ pwsh -c "Invoke-Pester Contoso/NestedModule2.Tests.ps1"

$ pwsh -c "Invoke-Pester Contoso/*.Tests.ps1"

Describe your environment

$ uname -a
Darwin QK24DX4PXW 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:53 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6020 arm64

PS > $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.3.6
PSEdition                      Core
GitCommitId                    7.3.6
OS                             Darwin 22.6.0 Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:53 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6020
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

PS >  Get-InstalledModule -Name Pester

Version              Name                                Repository           Description
-------              ----                                ----------           -----------
5.5.0                Pester                              PSGallery            Pester provides a framework for running BDD style Tests to execute and validate PowerShell commands inside …

Possible Solution?

No, my hope is that there is simply a misunderstanding on my side on how the containerization works. I pinky-promise, i've read through the docs multiple times already.

EDIT: For now, I'm doing some wrapping mania, to make sure that each test suite is executed within its own Powershell session:

PS > Get-ChildItem Contoso/*.Tests.ps1 | ForEach {pwsh -c Invoke-Pester (Resolve-Path -Relative $_)}

[tiararodney]

Ok, i think i figured this out for myself. The issue seems to be that I'm forcefully reloading the module for each test file invocation. Removing the -Force parameter from each Import-Module statement does the trick.

So i assume Pester collects all mocked functions for all test files before executing anything and I'm overwriting the mocks through forcefully reloading the original function.

So, why did I add the -Force parameter to the Import-Module statement and why am I even importing the module within each file? What I'm expecting from a test runner: Isolation for each test construct, which in this case is a file; additionally, each test construct should be executable independently. I'm not expecting to be required to write a wrapper, which does the module handling, at least that's the behavior I'm used to from other test runners (e.g. pytest, nUnit, jest, etc.).

[tiararodney]

I think it would be nice if there was a diagram which explained the order of execution. In addition, wouldn't it make sense as to a forceful module reload not change the mocking behavior? Should I open a feature request for that, or is my expectation too far off?

[tiararodney]

• referenced repository removed
• repository archive: pester-container-issue-demo.gitbundle.tar.gz