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. Thus, the code required change more frequently. Without the safety net of tests for the most basic logic, our feedback loop was slow as it required us to run builds and deploys to adequately cover our bases.

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.SshNet.dll")

function Get-FromSFtp {
    $fileList=$null
    try {
        $sftp=New-Object Renci.SshNet.SftpClient("127.0.0.1","test","test")
        $sftp.Connect()
        if($sftp.IsConnected) {
            $sftp.ChangeDirectory("/test")
            $fileList=$sftp.ListDirectory(".")
        }
        return $fileList
    } catch [Exception] {
        Write-Host $_.Exception.ToString()
    } finally {
        if(($sftp -ne $null) -and ($sftp.IsConnected)) {
            $sftp.Disconnect()
        }
    }
}

Here are a couple reasons why this code is difficult to test:

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. It turned out the extension on Object was the root issue so I investigated a pipeline based expectation syntax. Here is the result:

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!

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.