Tagging

Pester has a concept called tags. Tags apply to describe blocks and serve a variety of purposes. When designing tests, using tags can be a beneficial way to call certain groups of tests at once, or to exclude specific tests, or to change the test in other ways.

Introduction to Tagging

Perhaps you have lots of describe blocks scattered across a single test script. Since they are already in a single test script, there’s already some level of organization. However, tags allow for a different level of categorization than just grouping tests inside of a single script.

Without tags, when tests are in a single test script, you’ve only got two options for calling them. You can either run them all by simply executing the Invoke-Pester command and passing it the script path (Invoke-Pester -Path 'C:\Tests.ps1'), or you could run a single test at a time in that script using the TestName parameter on the Invoke-Pester command (Invoke-Pester -Path 'C:\Tests.ps1' -TestName 'foo'). You have no way to run a subset of tests or to exclude sets of tests.

For example, you have four describe blocks in a single test script that represent four functions. Each function is built around an object called Thing and is saved as Thing.Tests.ps1.

You’re working with a single object with multiple functions that perform various actions on that object.

describe 'New-Thing' {

}

describe 'Set-Thing' {

}

describe 'Get-ThingAttribute' {

}

describe 'Get-Thing' {

}

You’ve already got these scripts in a single test file which lets us invoke all the tests at once. But, in some situations, you’d rather not do that. Instead, you only want to invoke the tests that may modify things on the system, or those that are less intrusive and just read things. All kinds of reasons exist to group tests together.

For example, you can assign a tag to each describe block representing the action of each of those functions. Below, you’ve decided to use the tag Modifications to indicate a test for a function that changes things and ReadOnly for a test for a function that reads things.

describe 'New-Thing' -Tag 'Modification' {

}

describe 'Set-Thing' -Tag 'Modification' {

}

describe 'Get-ThingAttribute' -Tag 'ReadOnly' {

}

describe 'Get-Thing' -Tag 'ReadOnly' {

}

Once you have the describe blocks tagged, you can now use the Tags parameter on the Invoke-Pester command to run only those tests for each type of function as shown below.

PS> Invoke-Pester -Path C:\Thing.Tests.ps1 -Tags 'Modification'
PS> Invoke-Pester -Path C:\Thing.Tests.ps1 -Tags 'ReadOnly'

The reverse action also applies to tagged describe blocks without modifying the tags themselves in any way. The only difference is how you call the Invoke-Pester command. Instead of using the Tags parameter, you’ll use the ExcludeTag parameter to prevent specific tests from running.

PS> Invoke-Pester -Path C:\Thing.Tests.ps1 -ExcludeTag 'Modification'

The Tags parameter supports multiple tags as well so perhaps you have a different set of tags you’d like to apply to these functions too like Database, Server, whatever. Simply add another tag delimited by a comma, as shown below.

describe 'Get-Thing' -Tag 'ReadOnly','Database' {

}

Tagging Strategies

Because tagging can serve a multitude of purposes, let’s cover some examples of how others are using tags. I hope this section will give you some good examples of how you can use tags in your tests and help you come up with some tagging strategies of your own.

To use the tags in a systematic and structured way, I recommend first defining all of the tags you will be using. Setting tags upfront is especially crucial if you’re working on a team. Store available tags in a text file, spreadsheet, database, or some other place and stick to only using those tags. There’s no built-in way to manage tags in Pester so you’ll have to build your own simple storage and retrieval system.

General Strategies

Although some roles will have specific examples of tagging strategies, many of them have a standard set of tags that can be applied across any technology position. These tags can be used for just about any particular role.

Some examples of general tagging strategies are:

  • By Status:
    • Disabled
  • By Action:
    • Read
    • Modify
    • Remove/Create
  • By Operating System:
    • Windows 7
    • Windows Server 2019
    • Ubuntu Linux
    • MacOS
  • By Time:
    • NighlyBuild
    • AdHoc

For DevOps

Perhaps you’re on a software development team or in charge of automating builds and software releases. You have a continuous integration/continuous deployment (CI/CD) pipeline set up, and you’re using Pester tests to perform checks against test, QA, or production environments when the software is deployed. In a situation like this, you can define tags by a particular stack.

Maybe the software you’re deploying is a web application that allows users to log into an application with a backend database of some kind. Some useful tags might be:

  • By Stack:
    • Database
    • LoadBalancer
    • WebServer
  • By Feature:
    • NewUser
    • FeatureX
    • FeatureY
  • By Release:
    • v51
    • v4
  • By Deployment Stage:
    • Dev
    • UA
    • QA
    • Prod

For Sysadmins

Maybe you’re a system administrator and are using Pester to ensure your infrastructure is at a consistent state, no changes are being made without your consent. In this case, I’d argue for the point of a configuration management tool, but Pester tests are better than nothing!

Some example tags might be:

  • By Rights:
    • RequiresAdminPrivileges
    • RequiresDomainAdmin
  • By Server Type:
    • ActiveDirectory
    • FileServer
  • By Server Component:
    • CPU
    • Memory
  • By Cloud:
    • Azure
    • AWS
    • Google Cloud

For DBAs

For database administrators, Pester tests can provide significant value too. Since a Pester test is just a PowerShell script, you can write a test to check for anything you can read with PowerShell. For DBA, that could be:

  • By Database Vendor:
    • MicrosoftSQLServer
    • MySQL
    • PostGres
  • By Database Metrics:
    • PagingSpeed
    • ReadSpeed
    • Size

The options are limitless when it comes to coming up with tags to use. Remember to first come up with a pre-defined set of tests you and your team decide to use ahead of time and then assign the tags to your describe blocks and see what works for you.

Summary

Tagging is a simple but time-saving element of Pester. If you can assign tags in an organized fashion and track when specific tagged tests should be run, this tactic will save you and your team a ton of time over the long run. Tagging becomes more critical with the more tests you continue to create.

Up next

But Wait… There’s More