OutputFormat = "NUnitXml" $pesterConfiguration. ExcludeTag = $ExcludeTag $pesterConfiguration. # $pesterConfiguration = New-PesterConfiguration $pesterConfiguration. The cmdlet’s documentation page provides an explanation for all options but for some it is not clear what they really do. The main difference is that with version 5, the cmdlet is driven by a configuration variable that is initialized by the New-PesterConfiguration cmdlet. Basic execution still works but when the cmdlet is integrated in a CI pipeline like I do in the repository with the CI\Invoke-Pester.ps1, then you probably need to use some of the advanced functionality. The Invoke-Pester cmdlet has many changes when used in an “advanced” mode. Keep in mind that the extracts are relevant to the repository. To help showcase the requires changes, I’ll provide the relevant extracts from the V4 and V5. Soon, it became clear to me that that I would have to make significant changes which meant that I had to work on my PowerShellTemplate repository, where advanced Pester test cases are also covered.Īll the changes are available in this pull request and in the following sections I’ll focus on the major adaptations required. It turns out that there has been a new version (v5) of Pester which broke compatibility compared with the previous version (v4). I’ve not been hands on for a while and it took me some time to figure out that the tests were failing and why. One I have added in inline comments I’ll merge it with the master branch.Recently somebody submitted a pull request in my SemVerPS which failed with the Appveyor’s CI pipeline. I have put up the module at GitHub under the module POV (Pester Operational Validation) here. The reason why I do this is that in the final function I eventually created I wanted to add in parameters to pass through to the underlying cmdlet invoke-pester.īelow is a snippet of the heart of whats going on: On thing to note is that I create a called script. This would allow all the parameters needed for Pester to be in a csv spreadsheet and then I could use import-csv and foreach-object to pass through to the tool. So my idea was to pass the parameters as properties in an objects to the function and it would process the results. ie it had a main layer that held the path parameter and then it had a parameter layer that had the values in it. The format that Pester uses to accept multiple parameters was essentially a hash table with multiple layers. So I went back and rethought how I would create a function that would take any parameter and then process it. It wouldn’t adhere to the proper rules where we create a function to handle anything that you would throw at it. The problem was that it would only work on that particular Pester test. Invoke-Pester -Script in my function I could create a whole lot of parameters replacing the values and wrap it around a function…taking the above as an example I could create a pseudo function like so: June explained that the syntax would follow this: I thought that was great and so I decided that I would write a function that would put the values in for me. Then I came across an article that was written by June Blender called “How to Pass Parameters to a Pester Test Script”.Įssentially this article explained how to pass parameters into a Pester Test. One of the things that I found in this scenario is that when we write pester test, it seemed that we have to write a test for each node that we are testing. I could see the potential in writing operational validation tests as that is what we were essentially do when we do manual checks on server builds. I have been using Pester for operational validation purposes. So I have been really getting into Pester over the last few months using Pester.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |