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.
#Pester test code#
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. 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 test how to#
Learn how to get information back from Pester Learn about a new test framework for PowerShell called Pester
#Pester test 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.
0 kommentar(er)
