Pester can output test results to a XML file using the NUnit 2.5 schema.
TeamCity includes (since v4.5) a bundled XML Test Reporting plugin that can interpret the Pester Test Results file and include the test results in TeamCity's build dashboard. Configuring Pester and TeamCity to "light up" the Pester results is easy.
If you are using the Pester .bat file to run your tests, test results are automatically output to Test.Xml in the root of the TeamCity agent working Directory.
If you are not using the Pester .bat file and are instead calling Invoke-Pester directly from a build script, Make sure to specify a path using the
-OutputFile and type include the "-OutputFormat" parameters. The path is relative to the TeamCity agent working directory.
- In your TeamCity build configuration settings, go to the "Build Step" page.
- Add the "XML Report Processing" Build Feature.
- The Report Type should be set to NUnit. You can select version 2.5.0.
- In the Monitoring Rules text box, enter the xml file path given to Pester's
-OutputXmlparameter. If you use the Pester.bat file, simply enter Test.xml.
In some deployments of TeamCity it may be necessary to specify the Powershell version to use in the Invoke-Pester build-step -- specifying "5.1" has been observed to work.
If Pester does not seem to be available from your PowerShell build-step, here is an example on how to install it on-the-fly: https://david-obrien.net/2016/01/continuous-integration-with-teamcity-powershell-and-git/
Code coverage metrics are not included in the NUnit xml report so it is necessary to pass them to TeamCity separately using a PassThru variable and the Build Interaction feature.
The concept is the same: you serialize test results as
NUnitXml and then upload them to the CI test reporting system.
appveyor.yml can contain section like this
if check with
throw is used to fail the build, if any tests are failing.
Note: If tests write anything to the pipeline, then
$res object will contain it as well. Be careful!
That's it! May all your tests be green!
With Azure DevOps the concept is very similar again, you run pester then publish the results back to Azure DevOps. This can be done through a YAML configuration or through tasks run on the agent in the build pipeline.
An example of a PowerShell script to run against a single pester test file.
Then add a Publish Test Results task, it is important to change the Test Result format to NUnit to allow Azure DevOps to ingest the output file.
Note Using the Azure PowerShell task doesn't require you to enable the control option of "Continue on error" before the publish test results. If you use one of the Pester Marketplace tools your mileage may vary.