Pester itself is a child folder (the NuGet package includes all the tests as well). That’s because Pester runs files names *.tests.ps1 in the current folder and all child folder. 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.
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. You may need a solution file or something that NuGet can understand (nfig) just for the sake of using NuGet.
#INVOKE PESTER CODE#
You get the Pester code close to your own code and you know the version it has. NET developers and has a versioning story.
Given that you now execute your tests from within that folder you’d call Pester like this: (Pester is 2.0.3 at the time of this post)Īfter you’ve installed the Pester Nu Get package ( Install-Package Pester) you’ll get a ‘packages’ folder that contains the Pester files. NuGet has the concept of versions at least. If you’re working as a developer and want to use Pester for your library/scripts this is in my opinion the best choice. I mean…it’s not something compiled we’re getting it’s just a text file. You always have the option to go to github and grab the bits and copy them (or fork/clone) to your machine.
#INVOKE PESTER HOW TO#
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.Ī few different options exist depending on the context one might say. 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).įinally, kick it off with a call to Invoke-Pester. (Therefore I’m setting the current location to where my tests reside with Set-Location). Pester will, out of the box, locate files named *.tests.ps1 in the current directory and downwards. Import-Module "\Pester.psm1" # may be optional (btw this is the start of Roy Osherov´s StringCalculator Kata if you’re wondering): Let’s begin with a very quick example shall we. Note: All the code for this post can be found here. 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). Or is it?ĭisclaimer: I’m a BDD enthusiast and specifically I ‘m very fond of Specification by Example and the Gherkin syntax. It often deals a lot with external dependencies such as services and IO which are often hard to get under test. 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. Don’t let the word “script” or “shell” fool you, it’s still code. However when you’re constructing something that will survive over time and that others may use and improve, testing is extremely useful. Sometimes it definitely a place for ad-hoc code that just just executes once or twice just to accomplish something for the time being. I do believe, much like in any other language, that sometimes you don’t have the need to test your code (say what!?). So why on earth should you test your PowerShell scripts, are they not meant to be ad-hoc? 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. 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).
0 kommentar(er)
