Pester is a BDD inspired testing framework for PowerShell just like Jasmine is on the JavaScript side and RSpec is on the Ruby side for example (I do believe that JavaScript is one of the best comparisons for PowerShell though, it being a scripting language and all).

This blog post is meant as a quick introduction to what I think are the key take-aways of Pester and how I use it.

So why on earth should you test your PowerShell scripts, are they not meant to be ad-hoc?
I do believe, much like in any other language, that sometimes you don’t have the need to test your code (say what!?). Sometimes it definitely a place for ad-hoc code that just just executes once or twice just to accomplish something for the time being.

However when you’re constructing something that will survive over time and that others may use and improve, testing is extremely useful. Don’t let the word “script” or “shell” fool you, it’s still code.
PowerShell is often used in some sort of configuration scenario, may it be in a build/setup scenario for SharePoint or a deployment framework for your web application etc. It often deals a lot with external dependencies such as services and IO which are often hard to get under test. Or is it?

Disclaimer: I’m a BDD enthusiast and specifically I ‘m very fond of Specification by Example and the Gherkin syntax. This may (ok, it will) influence how I use the Pester framework which is really more leaning towards RSpec than Cucumber or SpecFlow (both being Gherkin family frameworks).

Note: All the code for this post can be found here.

1. Hello World

Let’s begin with a very quick example shall we. (btw this is the start of Roy Osherov´s StringCalculator Kata if you’re wondering):


$here = Split-Path -Parent $MyInvocation.MyCommand.Path
$sut = (Split-Path -Leaf $MyInvocation.MyCommand.Path).Replace(".Tests.", ".")
. "$here\$sut"
Describe "Add" {
    Context "when the input is an empty string" {
        $input = " "
        $expected = 0
        $actual = Add $input
        It "should return zero" {
            $actual | Should Be $expected

please note: StringCalculator.ps1, which has the Add function, reside in the same directory as the tests. (Line 1-3 dot sources that file into the test).

We’ll go trough all the different parts of a pester test shortly but for now you should know that Describe-Context-It-Should-Be are Pesterkeywords/concepts. (in PowerShell terms, they are functions).

Executing the tests (from a PowerShell  prompt)

Import-Module "[PATH_TO_PESTER_MODULE]\Pester.psm1" # may be optional

Pester will, out of the box, locate files named *.tests.ps1 in the current directory and downwards. (Therefore I’m setting the current location to where my tests reside with Set-Location).
Next, we’ll need to import the pester module (that may be optional if it has been added globally already as we’ll see examples of shortly).
Finally, kick it off with a call to Invoke-Pester.


Execute…watch it fail

…fix code…watch it succeed

…and now refactor.

2. Installation

So now that we’ve seen a simple example on how to use Pester we now need to find out how to get it onto our machine.
A few different options exist depending on the context one might say.


You always have the option to go to github and grab the bits and copy them (or fork/clone) to your machine.

Easy, fast.

The problem here is  versioning. I mean…it’s not something compiled we’re getting it’s just a text file.


If you’re working as a developer and want to use Pester for your library/scripts this is in my opinion the best choice. NuGet has the concept of versions at least. (Pester is 2.0.3 at the time of this post)

After you’ve installed the Pester NuGet package (Install-Package Pester) you’ll get a ‘packages’ folder that contains the Pester files.

Given that you now execute your tests from within that folder you’d call Pester like this:

Known technology to many .NET developers and has a versioning story. You get the Pester code close to your own code and you know the version it has.

You may need a solution file or something that NuGet can understand (packages.config) just for the sake of using NuGet.

I’ll try to come back to the Pester/NuGet story in a future post perhaps when I aim to speak about TeamCity and Pester.

A word of caution using NuGet

If your scripts reside in the same folder as the ‘packages’ folder (as the image above shows) here’s what can happen when you execute Pester.

See…it starts running the Pester test. That’s because Pester runs files names *.tests.ps1 in the current folder and all child folder. Pester itself is a child folder (the NuGet package includes all the tests as well).

So…you’ll need to do this:

I’ve moved my scripts (and tests) into a subfolder (‘src’) and when I call Pester I make use of the relative path parameter to point it to start in that folder.

Chocolatey or PsGet

Another alternative is to get the Pester bits onto your machine once, a.k.a. global install.
Here you can use Chocolatey or PsGet. I’m showing you the PsGet approach simply because I didn’t get it working with Chocolatey actually.

I’ll start by installing PsGet on my machine (I’m using Chocolatey for that):

And then it’s actually pretty easy:


Install once (handle updates once).

Hard to handle versions on the entire system like this perhaps.

3. Pester Specifics

OK, now let’s go into more details on some Pester things that might be good to know about.
We’ll start by looking at that beginning test for the Add function again:

A. Describe

Instead of a test case class, Pester (BDD) uses a “describe” block for one test case.
Describe is a function that takes two parameters: a string and a script block.
The string is a name or title for a spec suite – usually what is under test.
The script block is the code that implements the spec suite – { …some code…}

Personal comment:
My style of writing tests in PowerShell is more towards function per function so describe for me is the name of the function that I’m putting under test.
In a regular unit test this would probably have been my test class (fixture).

B. Context

Context is just an alias for describe. It is used to organize test code into different contexts.

Personal comment:
I like to think of this as my ‘Given’-clause where I’d like to setup my preconditions.  Or in AAA terms this is the ‘Arrange’ part .
Therefore I’m often writing it like “given [some condition]” (or “when [some condition]” but not in terms of the Gherkin-style when which describes the action)
Remember, this is your DSL so it’s very important that you feel comfortable with it and it makes sense to you.

C. It

Each test method is an “it” block. This would be the ‘act’ part.

Personal comment:
I often place my ‘act’ in the context part of the code as apart from the It-block.
This is just because of how Pester treats expectations and I might want to do multiple expectations on the same context.

D. Should

BDD style assertions are called expectations. Should is just a syntactic sugar that makes it more readable. Pester has a lot of very useful (readable) should expectations.

Personal comment:
I like to think of this as my ‘Then-clause where I check my post conditions.
Or in AAA terms this is the Assert part . Therefore I’m often writing it like “then [some condition]”.
Again, the DSL is important.

It’s Just Functions!

Since describe, context and it blocks are functions, they can contain any executable code necessary to implement the test. PowerShell scoping rules apply, so variables declared in a describe are available to any descendant block inside the suite.

4. Is that it?

This section will focus more on some personal “best practices” that I have found useful when working with Pester.

Using the file system and some useful tricks

A pretty common scenario for scripts might be to interact with the file system which is traditionally quite hard to handle with a test. Consider this:

If we want to put that function under test to verify that it indeed writes an error when the result.txt file is missing, how do we do that?
No worries, Pester has the answer:

First, we’ll need to make sure we can add and remove the file as we please. Pester has something called a TestDrive which is a temporary folder that the test has access to.
Let’s see it in action. Start with a failing test… (the TDD purist would probably scream now and say that you can’t write code before you have a failing test…well I just did so).

Indeed it fails and it fails because I couldn’t seem to figure out how to add the file (or setup my precondition so to say).
Let’s fix that.

Setup let’s us add file or folder to a temporary location that only exist throughout our test…then it is deleted.

Indeed the file is added but the test still fails. That’s because we’re not executing the that location, pretty common scenario…the working directory issue.
We’ll use another Pester thing…the In-construct to help us solve that issue.
Let’s see it in action.

I’ve wrapped the whole ‘interacting with file system’ part in a call to the In function that takes a path and a script block. The path is taken from the pester global variable $TestDrive. The code is now executed with that temp folder and happy day!

And now it’s green.

Now we can refactor, right?

Here we have the opportunity for some refactoring. As I see it the test code is now a bit ‘cluttered’ with that call to in.
What if I should make something that can combine a call to context and combine it with the in call.
Coding by wishful thinking…

What if our code could look like that instead. In my world that would be better.
What we wish to accomplish is:

  1. Change ‘describe’ to ‘fixture’ instead.
  2. Change ‘context’ to ‘when’ and add a parameter to it, WorkingDirectory, that allow us to set the working folder for the entire when function.

The first thing I’m going need is a common place to implement those ‘wrapper functions’. In an object oriented world we would probably call this abase class. In PowerShell it’s simply just a file that I’m importing into the test files. Like this (with a bit of refactoring on the importing parts as well):

OK and here are those functions that are now in the _TestContext.ps1 file:

Fixture just wraps the call to describe and adds some text around the call.

When wraps the call to context, with a prepended ‘when’,  and optionally executes the code in the in-clause if you provide a working directory.



Yes it can be done. Great examples already exist at the Pester wiki.

Pester: Unit Testing for PowerShell的更多相关文章

  1. Unit Testing PowerShell Code with Pester

    Summary: Guest blogger, Dave Wyatt, discusses using Pester to analyze small pieces of Windows PowerS ...

  2. Unit Testing with NSubstitute

    These are the contents of my training session about unit testing, and also have some introductions a ...

  3. [Java Basics3] XML, Unit testing

    What's the difference between DOM and SAX? DOM creates tree-like representation of the XML document ...

  4. Javascript单元测试Unit Testing之QUnit

    body{ font: 16px/1.5em 微软雅黑,arial,verdana,helvetica,sans-serif; }           QUnit是一个基于JQuery的单元测试Uni ...

  5. [Unit Testing] AngularJS Unit Testing - Karma

    Install Karam: npm install -g karma npm install -g karma-cli Init Karam: karma init First test: 1. A ...

  6. C/C++ unit testing tools (39 found)---reference API Sanity AutoTest Description: An automatic generator ...

  7. Unit testing Cmockery 简单使用

    /********************************************************************** * Unit testing Cmockery 简单使用 ...

  8. Unit Testing a zend-mvc application

    Unit Testing a zend-mvc application A solid unit test suite is essential for ongoing development in ...

  9. MVC Unit Testing学习笔记

    MVC Unit Testing 参考文档: 1. 2. ...


  1. 记录一次bug解决过程:mybatis中$和#的使用

    一.总结 mybatis中使用sqlMap进行sql查询时,经常需要动态传递参数.动态SQL是mybatis的强大特性之一,也是它优于其他ORM框架的一个重要原因.mybatis在对sql语句进行预编 ...

  2. 游戏编程技巧 - Type Object

    Type Object 使用场景 你在制作一款和LOL类似的游戏,里面有许多英雄,因此你想建立一个英雄基类,然后把各种英雄都继承自该基类,这些英雄类都有生命值和攻击力等属性.每次策划想增加一个英雄,你 ...

  3. 【PHP开发篇】一个统计客户端商机提交的获取IP地址

    1.对客服提交数据的ip地址记录. 获取ip地址的方法: public function getIP() { global $ip; if (getenv("HTTP_X_REAL_IP&q ...

  4. DFS序详解

    dfs序就是一棵树在dfs遍历时组成的节点序列. 它有这样一个特点:一棵子树的dfs序是一个区间. 下面是dfs序的基本代码: void dfs(int x,int pre,int d){//L,R表 ...

  5. DIV+CSS系统学习:转载

    第一部分 HTML 第一章 职业规划和前景 职业方向规划定位: web前端开发工程师 web网站架构师 自己创业 转岗管理或其他 web前端开发的前景展望: 未来IT行业企业需求最多的人才 结合最新的 ...

  6. MIT Scheme 使用 Edwin

    MIT Scheme 的基本使用: 安装过程 安装bre ...

  7. QTreeWidget

    #include "dialog.h" #include "ui_dialog.h" #include<QtCore> #include<Qt ...

  8. android实现通过浏览器点击链接打开本地应用(APP)并拿到浏览器传递的数据

    为了实现这个功能可折腾了我好久,先上一份代码,经楼主验证是绝对可以用的而且也比较清晰的代码!(ps:还是先剧透下吧,第三方大部分浏览器无法成功.) 点击浏览器中的URL链接,启动特定的App. 首先做 ...

  9. java通过jdbc连接impala

    下载所需jar包: 选择使用impalajdbc41版本 imp ...

  10. ngx_http_upstream_module模块学习笔记

    ngx_http_upstream_module用于将多个服务器定义成服务器组,而由proxy_pass,fastcgi_pass等指令引用 (1)upstream name  {...} 定义一个后 ...