Reporting Pester Code Coverage Metrics to TeamCity

As previously mentioned I’ve been doing a lot of work with PowerShell modules at work where I have recently gotten all the parts for a full continuous delivery pipeline working for those modules. A big section of that pipeline runs through TeamCity and while the existing ability to have Pester test results show up in the build results is really great, code coverage is slightly less obvious but in the end fairly simple.

The trick is to use the -PassThru parameter with Invoke-Pester and then use TeamCity’s build reporting interaction to get the values into the system. The end result will look a lot like this:

Pester code coverage right in your TeamCity build results!
Pester code coverage right in your TeamCity build results!

Simple test coverage check for script modules

I’ve been spending a lot of time at work writing PowerShell modules and as part of that effort we’ve been trying to make sure we’re doing at least some unit testing on those module functions (Using Pester of course!). Unfortunately we’ve had a few instances where a new function gets added to a module without any unit tests being added. We’ve structured our modules so that every function has it’s own source file and accompanying tests file and all of them are located in a \Functions\ folder in the project. Ideally the CodeCoverage parameter for Invoke-Pester would catch this sort of problem but it only runs tests for files with a certain file name structure and so if it runs across Some-Function.ps1 without an accompanying Some-Function.Tests.ps1 it doesn’t care. Today I finally got a little tired of finding broken functions and decided to do something about it, the result is Coverage.Tests.ps1:

I’ve got to think that it shouldn’t be hard to add a similar test for my other pet peeve: Missing help comment blocks!