#Pester test examples code#

Sure, you can run Pester locally, even from a git client-side hook, but ideally you want Pester to run automatically in your continuous delivery chain. tests.ps1, and execute them, counting up the errors and warnings and collating results, then it'll spit out a report of what's passed and what's failed, in detail. This will recurse through your directory structure, looking for files named something. To run pester tests, set your working directory to the root of the repo you want to test and run Invoke-Pester. There's a huge amount of scope for what can be done with Pester, and I'd advise checking out the documentation if you're interested. You can even Mock functions exported from Modules you've written, or from third-party modules. Note the use of splatting here, since in the actual test (which I cut down for clarity) we re-use our parameter values for several different scenarios. Obviously, we don't want this to actually send a Slack message every time we run a test, so we Mock Invoke-RestMethod, preventing the function from actually hitting up Slack, but allowing us to get an insight into the way the function executes. Import-Module PesterĬontext 'Checking what the module exports' | Should Not Throw Let's consider a simple, though not-particularly useful Pester test. Pester defines a Domain Specific Language for creating tests, mocks and assertions, and provides flexible ways to run your tests at any stage of the development process. Pester will soon be integrated into PowerShell 5.0, at which point there is no longer any excuse. It allows robust and flexible means of testing PowerShell code, just as NUnit and similar tools do for compiled. Pester is a community-driven BDD Unit Test framework for PowerShell. It's not the only project getting the Pester treatment, but it's the first to have Pester in place from day one. With it, we can do specialised auditing, deep querying and bulk updates, and while it's very much in the early stages it's already proving useful. We like to think it makes Octopus bigger and scarier, by automating against the API. Kraken is an Octopus Deploy management and monitoring library currently under development. The first project to get the Pestering treatment was the newest. And we're now integrating Pester tests into our PowerShell CI/CD chain. Luckily, a unit testing solution for PowerShell does exist, and it's called Pester. A lot of safeguards are built in, sure, but that part of the chain was lacking, for our PowerShell-based code at least. We still had to do our testing the old fashioned way, by running and observing the code.

#Pester test examples code#

The deployment on merge eliminated the need to fiddle about moving code around the place, but didn't ease the testing burden in any way.

Testing is a key part of the chain and at the time of writing, we didn't have a perfect solution. In the comments it was rightly mentioned that 'just because its code written by Ops, that doesn’t mean it shouldn’t have automated tests, nor CI'. A while ago I blogged about how our Ops code deploys on commit, and how Octopus Deploy, PoshServer and Github form that chain.