Table of Contents – Using Gherkin with Pester

It turns out there’s this whole thing called Gherkin. Before this chapter, all I knew is that I liked saying Gherkin, but that I didn’t really know much else about it (besides the whole cucumber/pickle thing). This single part of The Pester Book had just a single chapter in order to introduce us to Gherkin. I’m not going to try and explain it exactly. What I’ll do instead, is allow the book to partially do it for me. Here’s a quick couple of sentences from the text:

“Gherkin is a Business Readable, Domain Specific Language. It’s meant to decouple the business logic from the actual code being tested. It’s a language that can be used with any development language thus how we’ve been able to use Gherkin with PowerShell and Pester.”

That’s kind of neat, the whole, it can be used with any development language. I guess that’s why it’s in here. I did want to mention that Gherkin appears “…to be more suited for infrastructure testing rather than unit testing.” That’s probably a good thing to know.

Gherkin requires two files. There’s a .feature file and a .steps.ps1 file. One holds code, and one does not. The layout of these two files are specific in that the .feature file contains text description of how the tests will be structured (no code). The actual code — the tests — are located in the steps.ps1 file. These should be kept together inside the same directory with the script, or module, that is being tested. I won’t go into the layouts of each of the files, but it was certainly interesting to see, how each file was dependent on the other in order to execute the code — the tests. You’ll be glad to know that embedded within the .steps.ps1 files was PowerShell, and Pester, used to test the expected vs. the actual results.

I would recommend you work through and understand the example in the chapter. I didn’t really want to at first — I’m doing Pester, not pickle — but in the end, I’m glad I had some exposure to Gherkin, just in case it comes up another time.