Updated 22 Mar 2016 This task is available in the VSTS Marketplace
If you are using Pester to unit test your PowerShell code then there is a good chance you will want to include it in your automated build process. To do this, you need to get Pester installed on your build machine. The usual options would be
If you own the build agent VM then any of these options are good, you can even write the NuGet restore into your build process itself. However there is a problem, both the first two options need administrative access as they put the Pester module in the $PSModules folder (under ‘Program Files’); so these can’t be used on VSTS’s hosted build system, where your are not an administrator
So this means you are left with copying the module (and associated functions folder) to some local working folder and running it manually; but do you really want to have to store the Pester module in your source repo?
My solution was to write a vNext build tasks to deploy the Pester files and run the Pester tests.
The task takes two parameters
- The root folder to look for test scripts with the naming convention *.tests.ps1. Defaults to $(Build.SourcesDirectory)\*
- The results file name, defaults to $(Build.SourcesDirectory)\Test-Pester.XML
The Pester task does not in itself upload the test results, it just throws and error if tests fails. It relies on the standard test results upload task. Add this task and set
- it to look for nUnit format files
- it already defaults to the correct file name pattern.
- IMPORTANT: As the Pester task will stop the build on an error you need to set the ‘Always run’ to make sure the results are published.
Once all this is added to your build you can see your Pester test results in the build summary
You can find the task in my vNextBuild repo