Thanks for the link to the previous issue. I thought that had the best solution.

The ideal form of a script module is a single psm1 file and no dot-sourced scripts. Your approach is trying to shift the responsibility of what the module packager should be doing onto the import process.

Regarding the testing, Pester will let you test complete modules so all the tools are already there.

@rhubarb-geek-nz ,

Thanks for the feedback, what I meant with testing, is just testing the script(function) and not testing the whole module (which eventually comes at the end of the module deployment).
Meaning that your "best solution" requires someone to completely rebuild the module and fully test that for every single development step in the concerned script(function). Meaning that Pester might throw dozens of errors after your rebuild, where a simple direct check from the terminal prompt, like $InputObject | .\MyScript -Some parameters could have immediately reveal a simple scripting misstake. Besides, by rebuilding and reloading the whole module, you will loose the reference of how the the orginal function reacted in the prior full module release..

Besides by rebuilding and reloading the whole module, you will loose the reference of how the the orginal function reacted in the prior full module release..

Not really. That is all part of Test-Driven-Development and software versioning.

You should always be able to refer to how a previous revision behaves by simply running the previous revision of the module.

Likewise your tests should be written first and define how you want the module to behave. You write the code to meet the tests.

Your tests should alert you when your module changes in expected behaviour.

For every bug, defect, change etc add more tests to your suite so you are defining exactly how your module behaves and prevent regressions.