Recommended way to test internal/private functions of a module?

[J0F3]

Hi there,

I have a question regarding testing a script module with public (exported) and private (not exported) functions. I have a script module with quite some functions which are saved each in a separate .ps1 file. The files are saved either in the private or the public directory.
In the .psm1 file all functions get imported (dot sourced) and only these which are saved in the public directory get exported with Export-ModuleMember .

So I was now searching for a way to also unit test the internal/private functions of the module. It was some time since I used Pester the last time. Think it was version 4 or even 3 back then. So I am aware of InModuleScope but now I read in the documentation that it should no be used widely.

Currently I just dot source directly the .ps1 file with the function which I want to unit test, in a BeforeAll block. This works but has the drawback that wehen a function calls other functions I have also to dot source all the other functions so I can mock them correctly.
So I thought about just importing the module but then I have the problem how I can also test the internal/private functions without using InModuleScope a lot.

So what would be the recommended way to unit test also the private functions which are not exported by the module?

Because the module is quite complex I thought also already to convert it to a binary module (at least partially). But as Microsoft recommends Pester also to test binary modules the question stays.

Thanks!

[nohwnd]

InModuleScope is a bit problematic in Pester 5. But it can still be used if you really need it and understand the limitations.

One case where you should avoid InModuleScope is when you are testing a public function, that calls an internal function, and you need to mock that internal function. In that case Mock Some-InternalFunction -ModuleName <your module>, should be used instead, because then only the Mock is inserted into the module, but your test code is invoked from the outside of the module. This allows you to inject mocks, without exposing all the module internals to the test = you are sure you publish only what you meant to publish.

If you are testing an internal function, then using InModuleScope is your only option. In that case the best way is to put InModuleScope into each It block. Instead of around the whole Describe.

You can also quite safely put InModuleScope around the whole Describe, but in that case make sure to only import your module once. You should avoid Import-Module -Force on top of your every file. Or Remove-Module; Import-Module. This will leave you with tests that are bound to a module that is no longer imported and you will have problems that are very hard to debug.

[nohwnd]

That is up to you to decide. Depending what you are after. As you said, that is the difference between integration and unit test. I tend to write integration tests more, rather than unit tests, because they don't force me to know intimately how the module works line by line, and refactorings don't result if the need to rewrite a ton of tests.

[J0F3]

I tend to write integration tests more, rather than unit tests, because they don't force me to know intimately how the module works line by line, and refactorings don't result if the need to rewrite a ton of tests.

Yea, that makes definitively sense, good point.

Ok, thanks a lot! I think I know now how to proceed. 👍

[maccluu]

You should avoid Import-Module -Force on top of your every file. Or Remove-Module; Import-Module.

We have >50 modules and each of respective test files remove the module and re-import to make sure it has the latest code, for example at the beginning of each of our module's test file:

$currentLocation = Split-Path -Parent $MyInvocation.MyCommand.Path
$modulePath = Join-Path $currentLocation "$module.psd1"
Get-Module $module | Remove-Module -Force
Import-Module $modulePath -Force

All modules are tested in one pwsh session during one job, and it is during this all encompassing test, that I've started to run into PSInvalidCastException issues for test classes defined in the test files.

I'm curious whether you could expand on avoiding import-module in every file as I don't see it mentioned as a warning in the documentation for testing modules.

[schlich]

This reasoning should go in the documentation!

[maccluu]

@nohwnd - was wondering if you could comment on the Remove-Module being not recommended at the top of test files, as the issues it causes could leave in a difficult situation to debug. I wonder if this issue I raised but was unable to reproduce in a smaller set of modules is that situation:
#2241 (comment)