For those who have come across my blog before you would have seen my recent post on how to unit test PowerShell scripts that call SharePoint cmdlets, which after I posted started a conversation between myself and Jakub Jareš (PowerShell MVP and Pester Owner) around the approach I had taken and some of the flaws in it. What ended up coming out of that was a much better approach to what I was doing, as well as a massive refactor of my entire test suite for the xSharePoint DSC resources – so I wanted to capture the approach here for anyone else who is interested. Continue reading “Better approaches to unit testing PowerShell scripts that call SharePoint cmdlets”
Update: If you’re reading this then be sure to have a read of the comments too – some good insight and points from nohwnd on the Pester team that are also worth considering if you are interested in this stuff.
Update 2: I’ve posted a new post related to this which shows an improved way to test SP cmdlets
As we see PowerShell scripts get more and more complex (lets face it scripting guys, you’re basically writing code – we’ve turned you in to developers without you realising it! :P) people are discovering the need for things that help us maintain complex code bases, such as unit testing. Pester is a great tool for being able to write unit tests for PowerShell scripts, and will even integrate in to Visual Studio so you can run tests as you are writing your scripts. The way Pester lets us perform some pretty complex scenarios is through the ability to mock specific functions in a script, specifying what parameters to watch for in the input and what we will return from our mock – but for these mocks to work Pester needs to be able to see the original cmdlet or function you are mocking, which gets more complex in a SharePoint environment. Continue reading “How to unit test PowerShell scripts that call cmdlets from the SharePoint snap-in”