In the Beginning In 2010 I was on a project that focused on build and release software for a bunch of .Net projects (and a few Java projects). Our “glue” was written in PowerShell because of the wonderful remoting capabilities and it’s integration with Windows automation. Our code was untested and our code base was growing over time because our tools proved to be useful and we were getting more and more feedback. Read more...

Several months ago someone posted an excellent question on the Pester Group about a certain problem area in testing PowerShell with Pester. He brings up a relevant example of the difficulties that can occur when writing tests is done afterwards. It also reveals a missing feature of Pester. First let me display the code that needed tests: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Add-Type -Path (Join-Path -Path $psScriptRoot "Renci. Read more...

After a whirlwind of activity on the Pester codebase I’m happy to announce the latest release of Pester. Versions 1.2 and 2 are identical feature wise except for one subtle difference that I’ll get into soon. New Expectation and Matcher Syntax In prior versions of Pester, we have the dot notation expectation and matcher syntax $some_string.should.be("some value") This required some clever and downright nasty hacks to the PowerShell runtime. This created a few issues for some users and I wanted to get that fixed. Read more...

A few months ago I posted a simple tutorial on how to use Pester (a powershell bdd testing framework). I’m starting to practice the making of screencasts so I thought I would add some audio/visual to the blog post. I start rambling in the last 5 minutes so I won’t feel insulted if you stop paying attention after that part. Also, I want to thank Manoj Mahalingam and Martin Aatmaa for their feedback and contributions! Read more...

Hi there and welcome to my demo of Pester, a BDD style testing framework for Powershell. The creation of Pester came out of the desire to test some build/deployment infrastructure we were creating for a project. We wrote nearly all the code without tests and it came to bite us in the end. I wanted to find a way ensure these problems didn’t happen again as well as provide some code coverage to give new entrants to the codebase some confidence that they won’t break everything. Read more...