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
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:
1 2 3 4 5
Negative statements work too:
1 2 3 4 5
Extending the syntax is simply a matter of adding domain specific expectations, that follow the Pester function naming conventions, to your test suite:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
Pretty cool, eh? I feel that this can lessen the potential bloat of expectations in Pester and allow people to write test suites that fit their infrastructure domain model. The expectations are also very easy to test in isolation. The core matchers are pretty light, but they should be easy to modify now that matchers have test coverage unlike the previous syntax.
Adding your own matcher requires you to add 3 convention following functions. One that is the matcher, and 2 that return failure messages for postive and negative expectations. The biggest problem I see with this method is that if the convention ever changes, I’ll have to be very cautious and make it backwards compatible.
Thanks to Rich Siegel, Pester can now run blocks that fit a certain tag.
1 2 3 4 5 6
Another contributor is Max Bergmann who added NUnit style xml reporting to Pester runs. We are even using it in Pester’s own CI build. There’s some XML validation bugs that are still being sorted out.
Why 1.2.x and 2.0.x?
The motivation for this release is to fix the issues people have add where a
should property is added to every Object.
I’m not sure how exactly it was breaking things, but it was messy anyways, and I wanted to get rid of it.
1.2.x, you can disable the old assertions by running Pester with the
-DisableLegacyExpectations. This will
mean that your test suite has to only use the new pipeline style expectations.
2.0.x we disable the old style assertions and you need to explicitly enable them using the
-EnableLegacyExpectations switch. In the next significant release we’re going to remove the dot style assertions
completely from the codebase.
So if you’re upgrading Pester, then you should probably move to
1.2.x first. If you can run your tests with the
-DisableLegacyAssertions flag set, then you should be fine to move to
2.0.x. If you’re starting from scratch, then
What’s Left To Do?
Lots and lots of documenting. The
Get-Help pages need to be updated and I want to get pesterbdd.com up as soon as
possible. I think version 2 should be a fairly stable version of Pester.
If you’re interested in contributing to Pester please join the google group.