Extracting functions to enable unit testing

[BrianFarnhill]

Currently we are unable to perform automated unit testing of the xSharePoint modules as the machine that will run the tests needs to have the SharePoint binaries installed on it (so the Microsoft.SharePoint.PowerShell snapin is available locally). Since we can't install the binaries on each machine that will run the tests (such as the AppVeyor CI servers for example) we can't write tests using Pester to validate our get or set methods specifically.

An approach has been suggested where the SharePoint cmdlets could essentially be wrapped in a method that exists within xSharePoint, so that we can mock against the xSharePoint local methods to write the tests and still have the actual SharePoint cmdlets execute when it's pushed to a real environment. So for example in xSPServiceAppPool we have this line in the setter:

New-SPServiceApplicationPool -Name $params.Name -Account $params.ServiceAccount

This would be replaced with something like this:

New-xSharePointServiceApplicationPool -Name $params.Name -Account $params.ServiceAccount

and elsewhere in the module we would define New-xSharePointServiceApplicationPool as a function and use the @PSBoundParameters object to simply pass the call through to New-SPServiceApplicationPool.

This would mean that there would be many of these 'stub' methods throughout the module, increasing its overall size and making it a little less clear where things were called from. However we would gain much greater code coverage throughout the module, meaning that automated tests could pick up issues in logic sooner.

I would appreciate thoughts on the topic either in favour or against the use of these stub methods so we can have better tests.

[whozDougie]

Such a simple concept! Would love to see this in action say a video demo!

[anlynes]

Seems like a fair idea to me. Mocking has been a "thing" for ages and is not an onerous activity when compared to the benefits.

[prajeeshprathap]

@BrianFarnhill I've used FluentShellUnit to create a stub for SPWebApplication in my scripts. http://blogsprajeesh.blogspot.nl/2015/02/fluentshellunit-create-stub-from-script.html

If you want to write the unit tests using MSTest and want to test the scripts, then you can use the FluentShellUnit project from GitHub or from the nuget server

[BrianFarnhill]

@prajeeshprathap - love the idea, is there any way we could achieve this in something purely PowerShell based that we could work in to Pester? We need to line up with all of the other DSC Resources that execute tests in PowerShell with Pester, do you think we could adapt that C# in to script?

[prajeeshprathap]

@BrianFarnhill You can do the same with PowerShell as well. The idea is to create a proxy function for the SharePoint cmdlets after the context is loaded and then whenever you make a call to the actual cmdlets, the proxies will be executed.

http://blogs.technet.com/b/heyscriptingguy/archive/2011/03/01/proxy-functions-spice-up-your-powershell-core-cmdlets.aspx

[BrianFarnhill]

I have an approach to enable better unit testing without needing to stub all of the methods out in our script. I wrote a blog post on the topic and am almost finished incorporating this in to a pull request with the fixes and expanded test base. I'll close this issue once I push the script in to a pull request, but in the mean time here is the blog post on how it is done:

http://blogs.msdn.com/b/brian_farnhill/archive/2015/09/10/how-to-unit-test-powershell-scripts-that-call-cmdlets-from-the-sharepoint-snap-in.aspx

[BrianFarnhill]

This approach is now fixed to PR #78 and should be merged to dev shortly. I will close when the code review is complete

[BrianFarnhill]

This is now merged in to the dev branch and will be in the next release - closing this issue