PESTER CODE COVERAGE HOW TO
PESTER CODE COVERAGE SERIES
PESTER CODE COVERAGE WINDOWS

Make Disable-ADAccount do nothing, other than give us a way to track how it was called, so we know which users would be disabled.The test cases will make sure the proper objects are passed to Disable-ADAccount. We want some of these to be “disabled,” and others should be left alone. Make Get-ADUser return a set of test objects.Make Get-Date return a specific date and time.To test this code without requiring an actual Active Directory domain, we need to consider a few things: (The function is written this way instead of using the better Search-ADAccount cmdlet simply to give us more to work within the Pester examples.) Of these, we can ignore Where-Object because it’s simply a logic construct-and indeed, it is what we’re testing. This is a fairly simple function, but it contains calls to four other cmdlets: Get-Date, Get-ADUser, Where-Object, and Disable-ADAccount. A picture is worth a thousand words, so here’s a sample of a PowerShell function that needs some mocking to be properly unit tested: Pester has a built-in mocking framework that allows you to create dummy versions of other PowerShell commands. For a unit test, though, we need some way of isolating our function under test from its dependencies. They make calls to an API (without caring what its internals do), and write test cases against the results. The examples of Pester that you’ve seen so far are perfect for integration or acceptance tests. You might also hear these referred to as “smoke tests.” You can use them as a quick sanity check to make sure everything’s up and running. Acceptance testsĪcceptance tests are fundamentally the same as integration tests, except they refer to tests that you run after your code is deployed into production. It’s for this reason that you only move on to integration tests if the unit tests have already passed. This means that integration tests are more expensive to run. This might require you to set up a more complicated test environment, so the necessary web services, for example, are available. Instead of isolating your code from the other parts, you run everything in all its glory, and make sure it’s behaving properly when all of the bits are working together. Integration tests are pretty much the opposite of unit tests. These dependencies could be anything, including a web service of some sort, the state of the computer where the script runs, or even calls to other PowerShell functions or cmdlets. If the function you are testing depends on anything other than the parameters that are passed in, you’ll want to isolate your code from those other dependencies in the unit test. Unit tests are responsible for verifying the behavior of a single unit of code, which in PowerShell, typically means a function. It can usually be executed on the developer’s machine before checking in the code to source control.

PESTER CODE COVERAGE WINDOWS

For the purposes of Windows PowerShell code, I tend to refer to three:Ī unit test is the smallest and fastest type, and it is the first thing that will be run in your pipeline. There are several categories of automated testing, all of which are used in a continuous delivery pipeline.

Use Pester for testing PowerShell modulesīefore we get into the technical details today, let’s define a few terms.

Use Pester to analyze small pieces of Windows PowerShell code

Unit Testing PowerShell Code with Pester.

PESTER CODE COVERAGE HOW TO

Learn how to get information back from Pester

Learn about a new test framework for PowerShell called Pester

PESTER CODE COVERAGE SERIES

Note This is a five-part series that includes the following posts: Summary: Guest blogger, Dave Wyatt, discusses using Pester to analyze small pieces of Windows PowerShell code.

Pester code coverage