Each module has its own private scope area where it can store its functions, variables, and aliases, which is entirely separate from the scope of the caller. It turns out that this is due to how PowerShell script modules work. What happens if we try to mock or execute the internal GetUsersToDisable command instead? You clearly mocked the Get-ADUser command to return a set of test objects, so why the heck did the tests try to contact an actual Active Directory server? When this happens to you, you may understandably start cursing the incompetent people who wrote this Pester thing. Here’s what happens if I run Invoke-Pester on this file as-is: For a refresher, here’s what that tests file currently looks like: The Tests.ps1 file is fine as-is, with the small exception of calling Import-Module instead of dot-sourcing a. psm1 file, and added a small change to introduce an internal function: To demonstrate this, I’ve taken the code from yesterday’s Active Directory example, placed it into a. This can get a little bit trickier when you start to store your code in script modules (.psm1 files). Yesterday, we looked at how to use the Mock and Assert-MockCalled commands in Pester to unit test the logic in your PowerShell code without having any external dependencies. Use Pester for testing PowerShell modules Use Pester to analyze small pieces of Windows PowerShell code
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |