I’ve previously written blog posts about Pester. The first one was a general purpose overview. The second one was about working with modules and Pester.
The whole, original, purpose for me using Pester was to get a bit of quality around a PS module I’ve written called TSR. So the last part of the whole story is to wire up TeamCity (yes that’s my preferred choice) to execute the unit tests before packaging the module up as a nuget package ready for publishing.
1. Prerequisites
1.1 Get the Pester bits onto TeamCity
In the first post on Pester I mentioned three ways I could think of:
- Manually, i.e. copy the bits from github.
- Use nuget, Install-Package Pester.
- Use PSGet (or Chocolatey). Same end result though.
Let’s briefly discuss options 2 and 3.
option 1: NuGet – per project install
As mentioned earlier the big advantage to using nuget is that you get a version story in place built in.
The disadvantage is that nuget normally doesn’t have a great story without Visual Studio, i.e. it’s a lot more manual. But let’s take a look at some options.
No matter how you choose to use Pester on your own machine (I usually use the PSGet/Global install approach) it’s quite different when you want to run the same tests on another machine, such as a TeamCity server.
Since PowerShell usually doesn’t have a Visual Studio solution file, and thus no packages.config if you haven’t created one yourself, you can’t use “normal” package restore.
You have to either:
- add the Pester nuget package to version control (not recommended). This will actually be much the same as adding the bits manually.
- install the Pester nuget package as part of your build configuration.
I’ll show you how to use the second approach since that I think will be the preferred way.
As long as you’ve got the nuget.exe available it’s really easy to install a package. And since TeamCity comes with a nuget command-line feature it’s also really easy to use the “TeamCity nuget.exe” if you’d like to (there are parameters available that gives you the path/s you’d need).
Shameless plug: I’ve already made a meta-runner that you can use for this very purpose. Download it from here.
That installs the Pester nuget package into a folder called packages at the root of the TeamCity checkout directory.
You just have to remember to place the “install” runner before any other runner that wishes to use Pester.
option 2: PSGet – global install
The other option, as far as I see it, is to install the Pester module globally. Then it will be available globally. Log on the TeamCity server and install PSGet and then run:
Install-Module Pester -Global
The disadvantage to this approach is that you really don’t have a built-in version story. The up-sight on the other hand is that you only have to install it once.
Update 2013-10-15: I’ve added a post on how to “overcome” this.
1.2 Build Feature – Test Results
Pester can output a test report if you’d tell it to. In TeamCity we can make use of this report to give us some extra information. Here’s how.
Add a build feature (XML report processing) and configure it to match your setup.
note: if you use the pester.bat file included with Pester the file will be named Test.xml in the same directory as your tests. (image above reflects that)
1.3 Build Feature – Swabra
Swabra can monitor paths of your choice and make sure that you checkout directory is cleaned. Since Pester will add a test result file this will make sure that such a file is removed before we start a new build.
2. Execute Pester
Puh, well now it’s time to get those unit tests running…
We’ll examine two different options (just to show you that it’s possible) here too.
2.1 pester.bat
Pester comes with a bat file that will trigger the execution of the tests. Let’s first try out that approach.
note: I’ll use this approach as if had used the nuget install option mentioned above.
This is a command-line build runner.
I’ve configured the working directory to where my tests reside (1).
Then just execute the pester.bat (2) which is located in the tools\bin directory. Note that instead of “packages” as the nuget output directory the “lib” directory is the output in the example above.
2.2 Invoke-Pester
If you’d like a little more control (or just prefer it) you can use a PowerShell runner instead to trigger Pester.
note: I’ve used the PSGet install option for this approach just to show the difference.
Same as with the command-line option I’ll set the working directory to where my tests are. Next, just invoke Pester:
Invoke-Pester -OutputXml Test.xml
Result
No matter which approach you prefer you’ll end up with something like this:
Johan Leino 