“There’s no sense in being precise when you don’t even know what you’re talking about. -John von Neumann”
I thought this was a good quote as the theme for this post. Re-read the quote, take it in, and then continue reading.
During the construction of a set of Pester tests, it can be increasingly difficult to follow the flow of each of the tests and the subjects against which these tests will be performed.
Since Pester tests PowerShell code, you are able to use a PowerShell method called Regions to separate section of code. These Regions will allow you to collapse large sections of similar code to create an overall more pleasant script reading experience. While that may assist to some extent, it does not help you find and run specific tests.
Here’s an example of what using a region would look like:
The problem is that this technique is only useful when reading code, but not necessarily nearly has helpful when executing code. A region doesn’t allow you to pick out precisely what test you want to run. That’s where using Tags comes into play.
Tagging is a Pester parameter that allows you to filter Describe blocks using a string or keyword value. When using Invoke-Pester with the
-Passthru parameters, only the
Describe blocks that contain the
-Tag value specified will execute.
Here is a simple example:
This is useful because you do not have to have multiple test files with only one
Describe block in each, you could instead create a single master file with multiple
Describe blocks, each with their own
tag. This is very useful to do when you have an application or infrastructure stack you want to test, and have the ability to add any new regression tests you may need in the future.
You can use multiple tags for a
Describe block, but you cannot use multiple
tags when running
Invoke-Pester. This took me a little time to figure out but after thinking about it, it does make sense. You want to run a single or suite of tests that have the
tag, not multiple tests with multiple tags because that is what
Invoke-Pester will do by itself!
Since I first started learning about Pester, I have been building a few infrastructure tests for use in the environments I work in often. One particular task involves working with domain controllers and occasionally do some investigation into replication issues.
Taking what I know and turning it into some tests that run quickly and uniformly has improved my response time to domain controller issues. Tags have been extremely helpful during a couple of troubleshooting tasks now that I could target the specific failed component(s) in my test set based on results of the initial test.
There is no reason to keep running full tests for example if, for example, DNS is not working. I can then target DNS services and infrastructure without chasing other possibilities, thus wasting time. Another benefit was that I did not have to go find additional scripts because I already had the
-tag parameter set for the Describe block in question.