Gherkin is a language for defining software requirements entirely in human-readable form, with no executable code whatsoever. Speaking of community contributions, here are some of the neat features we’ve got coming up when version 4.0 of Pester gets released: Gherkin But don’t take my word for it-prove it with tests!īy the way, many of the ideas and code for these cool features came from the community! If you have a feature that you think would make your tests more valuable or easier to write, please head to Pester GitHub site and open an Issue (or, if you’ve already written code, open a Pull Request) to strike up a conversation about it! You can access it via a variable named $TestDrive, or with a PSDrive named TestDrive:\. At the end of the Describe, the folder is deleted.
This is a folder created under your TEMP directory at the beginning of each Describe block. If your script needs to create temporary files on the hard disk, Pester provides a means for that with a built-in test drive. You can place them into your code in any order, and they’ll still work, for example: Unlike most PowerShell code, these commands work a bit of magic. Pester will guarantee to run them at the begin and end of each It block (for the Each versions), or at the beginning and end of the Describe or Context block (for the All versions). These are initialization and cleanup blocks.
Invoke-Pester can be called with the –Tag or –ExcludeTag parameters to control executing by tag, rather than by name.Īnother feature available for your convenience is a set of commands named BeforeEach, AfterEach, BeforeAll, and AfterAll. Each call to Describe can optionally include the –Tags parameter to assign one or more tags to the block.
Another way to run a particular Describe block or a group of Describe blocks is to use tagging. I snuck in another feature demonstration with the –TestName parameter. This property contains detailed information about the analysis, which you can use in your build pipeline if desired. If you use the –PassThru switch at the same time, the object will include a CodeCoverage property. The –CodeCoverage parameter was passed a path to the file that you wanted to analyze, and the –TestName parameter specified which Describe block to run. To show that in action, I’ll run the tests from yesterday’s final script module example, using a –TestName filter to only run one of the Describe blocks: (This doesn’t necessarily guarantee that your tests are covering all the logic of the “hit” commands, but at least you can be certain that if a particular line of code didn’t execute during your tests, you definitely didn’t test that part.) Pester can help you keep track of this metric by analyzing your code as it’s being tested, and reporting on any PowerShell statements that were not executed during the test. Today, I want to show you a few of the other features that the module has to offer.įirst, coverage analysis! The term “code coverage” refers to how much of your code is actually tested.
I hope that this series has convinced you that writing Pester tests for your code can be easy and valuable-even if I had to be fairly brief in my examples of the most essential parts of the module. Use Pester for testing PowerShell modules
Use Pester to analyze small pieces of Windows PowerShell code Unit Testing PowerShell Code with Pester.
Learn how to get information back from Pester Learn about a new test framework for PowerShell called Pester Note This is a five-part series that includes the following posts: Summary: Dave Wyatt wraps up his week teaching us about Pester with information about more resources.