Mocking functions in Pester is easy, you just use Mock and you are done. But how do you mock a method on an object?
Mocking functions in Pester is easy, you just use Mock and you are done. But how do you mock a method on an object?
Few days ago I posted about a tiny module I wrote to skip the entry point function in a script. I got few reactions telling me that there are better ways to organize your scripts, and they were all correct. Putting your code into a module and distributing it that way, or splitting the script into different files and combining them during build are both better than having a single file with everything.
Testing a self-contained script file with Pester is difficult. I visited this idea few times before, for example here and never reached a solution that I would like, but every time I am getting closer and closer.
Seven years ago, on the first day of 2011 the first commit to Pester repository was done by Scott Muc. Little did he know that this minimal implementation of a testing framework, he committed still a bit drunk from the previous evening, will grow into the number one PowerShell testing framework it is today.
Writing a test framework is a lot of fun, and presents some unique challenges to overcome. One of them is testing your assertions. I am writing my own set of assertions for Pester and I also used the same ideas to test some of the Should assertions in Pester.
This weekend I added type filter and -PassThru to Should -Throw. Let’s see how are they useful.
🔥 This feature is not released yet, get pre-release version 4.2.0-alpha3 to use it.
Filtering exceptions on type is one of the most basic capabilities of any assertion that deals with exceptions, yet we were missing it till now. But there it is now:
This weekend I added custom failure reasons into Pester. This feature I know and love from Fluent Assertions, so let me show you how I would use it in Pester.
🔥 This feature is not released yet, get pre-release version 4.2.0-alpha3 to use it.
The new feature adds an optional -Because parameter to all Should assertions. The parameter allows you to specify a reason that will be shown when assertion fails, like so:
This always starts of as a joke:
So do you test your tests? When you test your tests, do you test the tests that test your tests?
And people are often surprised that I in fact do test my tests.
With Pester there are two different ways of testing that both look very similar, but are in fact very different.
I am using PowerShell version 5.0.10018.0 for the examples. This version of PowerShell ships with the WMF February 2015 Preview package that you can download here.
I was asked if there are any resources on testing class based DSC resources. And to be honest I am not sure. We shortly discussed the possibilities on the PS MVP mailing list, but I am still not sure what are the possibilities. So why not discover them while learning something more about the topic.
Luckily there are quite a few great resources on how to actually create a class based DSC resource, and what you need to do that. Some of them are:
Creating a Class based DSC Resource using PowerShell
Class-defined DSC resources in Windows Management Framework 5.0 Preview
Writing a custom DSC resource with PowerShell classes
Lately we are getting some great questions on our Pester issue page, I am reposting soem of my answers as blog posts, because I hope they are worth reading. You can access the original question here.
We test because we need a simple set of boundaries that define a more complicated system. Coming up with simple tests and gradually refining them to define more complex systems is easy for us humans. Definitely easier than defining a complex system in a single swoop.