Monday, 26 September 2016

Pain-points Pester and Perseverence

Listen up dudes! We need to write some unit tests for all these PowerShell functions we have been writing. Why? Because we need to make sure our code does what we think it does and only what we think it does. Yeah, I know we test the functions manually when we use them but we are pretty limited in our ability to monitor what our code is doing under-the-hood unless we get some kind of verbose output. Even then, we don't know what we don't know. With the use of a testing framework (like Pester) we can test each function and isolate its inputs and outputs to make sure that thing does only what it is told!

If you have got this far, like I did a while ago, and you have watched a few intro videos (like this one and this one ) and you have downloaded Pester from GitHub ( and you have copied the extracted folder to the PowerShell modules directory; then you may just hit these issues working in Visual Studio:

  1. VS Test Runner fails your embryonic unit test because it can't find the Pester module:
    Check the name of the folder in the PS Module directory and make sure it is called "Pester" rather than "pester-master" which is what it extracts to
  2. VS Test Runner fails your test because PowerShell's Execution Policy doesn't allow Pester's scripts to run:
    The PS execution policy is causing the issue. Unblock the Pester ps1 files using the Unblock-File cmdlet.
  3. Your test doesn't show up in the VS Test Explorer
    Check that you are not using dynamic names for your Describe block, the test explorer doesn't know what to do with those.
Now to write some grown up unit tests...

No comments:

Post a Comment