{"id":80418,"date":"2018-08-16T16:32:49","date_gmt":"2018-08-16T16:32:49","guid":{"rendered":"https:\/\/www.red-gate.com\/simple-talk\/?p=80418"},"modified":"2025-12-17T14:05:23","modified_gmt":"2025-12-17T14:05:23","slug":"introduction-to-testing-your-powershell-code-with-pester","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/sysadmin\/powershell\/introduction-to-testing-your-powershell-code-with-pester\/","title":{"rendered":"Introduction to Testing Your PowerShell Code with Pester"},"content":{"rendered":"

The series so far:<\/strong><\/p>\n

    \n
  1. Introduction to Testing Your PowerShell Code with Pester<\/a><\/li>\n
  2. Advanced Testing of Your PowerShell Code with Pester<\/a><\/li>\n
  3. Testing PowerShell Modules with Pester<\/a><\/li>\n<\/ol>\n\n\n\n\n

    Automation has become the backbone of infrastructure management within most corporations. The DevOps movement has added to the importance of having a good automation strategy. With its usefulness on the Windows platform long established, and now the ability to run on the Linux and Apple Mac OSX platforms, PowerShell has firmly established itself as a powerful player in the world of automation.<\/p>\n\n\n\n

    Given the importance of PowerShell, imagine that your boss, project manager, or similar authority figure comes to you with some basic questions.<\/p>\n\n\n\n

    \u201cHow can I be confident your code meets requirements?\u201d<\/em><\/p>\n\n\n\n

    \u201cHow do we know your changes don\u2019t break other modules?\u201d<\/em><\/p>\n\n\n\n

    \u201cCan you prove to me your scripts do everything they are supposed to?\u201d<\/em><\/p>\n\n\n\n

    These and other questions can be answered through the use of testing.<\/p>\n\n\n\n

    Pester<\/h2>\n\n\n\n

    \u201cSure\u201d you say. \u201cI test my code.\u201d But in a shockingly high number of environments testing is still a manual process. A developer makes changes, runs a test on their computer, and deploys. Unfortunately, this type of testing just doesn\u2019t scale. A developer may be able to test the small script they created, or the function they updated. But what about bigger code bases? Modules composed of multiple PS1 files, or scripts that rely on many different modules?<\/p>\n\n\n\n

    Just as automation is the answer to infrastructure management, so too is it the answer to testing. From the title of this article, you\u2019ve guessed by now the tool of choice for testing PowerShell code is Pester.<\/p>\n\n\n\n

    Pester is a community-based project designed from the ground up as a testing framework for PowerShell, written in PowerShell. It\u2019s open source, you can look through the source code, even make contributions back to it. You\u2019ll find the full project<\/a> on GitHub.<\/p>\n\n\n\n

    A lot of effort went into making Pester as compatible as possible across multiple versions and platforms. It is compatible with PowerShell 2.x up through 5.x on Windows 10, 8, 7, Vista, and all versions of Windows Server from 2003 through today. It is even compatible with the new PowerShell 6.0 Core, running on Linux\/Mac OSX platforms, with a few minor limitations. (See the article Pester on PSCore limitations<\/a> for more information).<\/p>\n\n\n\n

    In this series of articles, I\u2019ll introduce Pester and show examples of the different types of tests you can perform.<\/p>\n\n\n\n

    Types of Testing<\/h2>\n\n\n\n

    Before getting into writing tests, I will cover the types of testing. These break into three basic categories. While there are entire books written around testing concepts, this will be as brief as possible to provide context to basic testing operations.<\/p>\n\n\n\n

    Unit Testing<\/h3>\n\n\n\n

    Unit tests are performed by the developer and are typically focused on the code they\u2019ve just created or modified. They provide feedback that the code works as they wanted it to. Unit tests are done in isolation<\/em>. By isolating the test to run on just the code they\u2019ve written, and not that of external modules, they can be assured any problems they find are with their code and not with external modules or functions.<\/p>\n\n\n\n

    To achieve isolation, testing uses the concept of mocks<\/em>. Within a test a mock is used instead calling the actual external function desired. For example, let\u2019s say your script calls Test-Path<\/strong> to validate the existence of a file. Actually, calling the real Test-Path<\/strong> function could cause several issues in testing.<\/p>\n\n\n\n

    First, the Test-Path<\/strong> cmdlet itself could have a bug in it, previously undiscovered or maybe just not known to the developer. Second, the developer could be assuming the path containing the file they are seeking will always exist as part of the test. Issues would certainly arise if the directory was to unexpectedly vanish. Finally, the drive containing the file may not be present or issues such as network connectivity or hardware failure could be causing problems.<\/p>\n\n\n\n

    Should any of these issues occur, the developer is left not only trying to debug his own code, but also struggling with the many ways the Test-Path<\/strong> cmdlet could have failed.<\/p>\n\n\n\n

    Mocks provide a way to remove external code, such as Test-Path<\/strong>, from the equation. As you will see later in this series, you can create a \u2018fake\u2019 or \u2018mock\u2019 version of Test-Path<\/strong> that would always return a true (or false). This removes the external call (in this case to Test-Path<\/strong>) as a possible vector for errors a developer might have to track down. The next article in the series will dive deeper into mocks.<\/p>\n\n\n\n

    Integration Testing<\/h3>\n\n\n\n

    Integration testing is the next step in your testing workflow. Once a developer successfully completes their unit tests, they are ready for integration testing. Integration tests go beyond just testing the code the developer has finished working on, to testing it along with all the related code for a project.<\/p>\n\n\n\n

    For example, let\u2019s say you updated two functions in module A. This module is part of a bigger project that encompasses two other modules, B and C, in addition to A. When executing integration tests, it would call all of the tests for all three modules. This is to ensure changes to module A don\u2019t adversely affect modules B and C.<\/p>\n\n\n\n

    Typically, integration tests do not employ mocks. To fully test integration, in addition to your own code, you should execute that code against other modules. These modules might include some you\u2019ve purchased, or those provided by Microsoft such as AzureRM<\/strong> or SqlServer<\/strong>. Integration testing is often considered \u2018white box\u2019<\/em> testing. In white box testing, also referred to as clear box or glass box, the tester has access to the underlying source code.<\/p>\n\n\n\n

    Many source code control systems have the ability to automatically perform integration testing. Once code is checked in, the system will automatically execute the integration tests you\u2019ve configured.<\/p>\n\n\n\n

    Acceptance Testing<\/h3>\n\n\n\n

    Acceptance tests should be done by someone other than the developer. Some companies have internal organizations set up just to perform testing. In other organizations business users are often employed as testers, although this isn\u2019t as common when testing non-application projects such as PowerShell scripts.<\/p>\n\n\n\n

    Acceptance testing is typically done in a \u2018black box\u2019<\/em> style. In black box testing, the testers do not look at or have access to the source code. Instead they simply execute the scripts and look at the results. If the results are as expected, for example a new server is created or database is deployed, the test passes.<\/p>\n\n\n\n

    When to Test<\/h2>\n\n\n\n

    Let\u2019s say by the end of this series of articles, you\u2019re sold on testing your PowerShell code with Pester. You\u2019ll want to start by crafting tests for the modules and scripts that you already have. Typically, these tests are written against what you expect the code to do. While you might think your tests would all just pass every time, you\u2019d be surprised at how often you uncover bugs in your existing code when creating tests. Additionally, the creation of these tests will give you a base for testing new updates to your scripts.<\/p>\n\n\n\n

    The second time to test is before you write your scripts. Yes, you read that right, you should create your tests before<\/em> you write your new scripts (or update existing ones with new functionality). The concept is known as test driven development<\/em>, or TDD for short.<\/p>\n\n\n\n

    With test driven development, you begin with your requirements document. You then create a test for each requirement. In addition, you\u2019ll also want to ensure you create tests for failures. For example, say your requirement is to download a file from a website via FTP every day. Naturally you\u2019ll have a test for successful downloads, but you should also have tests for when the download fails to ensure your code behaves according to the requirements for error handling.<\/p>\n\n\n\n

    TDD also helps us to answer the question of \u201care we done\u201d. If you have tests for each requirement when all of your tests pass, you\u2019ve met all of your requirements, and thus development is complete.<\/p>\n\n\n\n

    As should be obvious, in order to properly do test driven development you must have good, clear, and documented requirements. I cannot stress how important this is. In far too many development shops, requirements are provided with a few scribbles on the back of a napkin, or even worse, verbally.<\/p>\n\n\n\n

    Your automation strategy is a critical component in your corporation\u2019s infrastructure. Even a small script with just a few lines of code can have an enormous impact in your company. Imagine a simple script meant to remove a single resource group from Azure. Improperly configured, it could wind up deleting ALL of the resource groups, including those in your production environment!<\/p>\n\n\n\n

    Demand clear, well written requirements. If you cannot get them, then write them yourself! Base them on your understanding of the user\u2019s needs. Once done, send them to the user, letting them know development will proceed once they provide formal approval via email.<\/p>\n\n\n\n

    The Demos<\/h2>\n\n\n\n

    The demo code for this series of articles was written on Windows 10, 64-bit, using PowerShell 5.1. The code was developed in the PowerShell ISE.<\/p>\n\n\n\n

    For all of my PowerShell articles, a root folder on the C drive was created, C:\\PowerShell<\/em>. For this article, a new folder Pester-Demo<\/em> was generated, hence C:\\PowerShell\\Pester-Demo<\/em> is where all the code is being executed from. However, you are not locked into this structure. To make it easy at or near the beginning of each script is a variable, $dir<\/strong>, which points to the demo folder. Just update this to point to the folder you want to place the demos in.<\/p>\n\n\n\n

    $dir = 'C:\\PowerShell\\Pester-Demo' <\/pre>\n\n\n\n
    In addition, the final set of demo scripts for can be found on the author\u2019s GitHub repository<\/a> for this article.<\/p>\n\n\n\n
    Installing \/ Updating Pester<\/h2>\n\n\n\n
    Installation of Pester is pretty simple if you are using PowerShell version 5.x (5.0 or 5.1). As version 5 is the most widely used version today, I\u2019ll cover installing using it below. If you are still on an older version of PowerShell the Pester site on GitHub has clear instructions<\/a>.<\/p>\n\n\n\n
    Assuming you are on PowerShell version 5.x, you can find out what version of Pester is currently available by using the Find-Package<\/strong> cmdlet.<\/p>\n\n\n\n
    Find-Package Pester<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    <\/p>\n\n\n\n
    As you can see, as of this writing, 4.4.0 is the most recent version as of the date of this article. To install it, simply use the Install-Module cmdlet, but be sure you are running the ISE or PowerShell console in Administrator mode or the install will fail.<\/p>\n\n\n\n
    Install-Module Pester -Force -SkipPublisherCheck<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    If you\u2019ve previously used Install-Module<\/strong>, the switches may not be ones you\u2019ve used before. Force<\/strong> will do the install even if you have Pester installed. The SkipPublisherCheck<\/strong> argument is important if you are running on Windows 10. As mentioned before, Pester was pre-installed on Windows 10. However, the code was installed using a code signing certificate that is different from the one used today on the GitHub \/ PSGallery version. Because the certificates don\u2019t match, PowerShell will raise an error and not allow you to proceed. Normally this would be a good thing, as it would prevent evil hackers from trying to overwrite a module you trust with one of theirs. In this case, though, you are cognizant of what you are doing and are requesting the update. Hence, you need the SkipPublisherCheck<\/strong> as a way to tell PowerShell you know the certificates don\u2019t match, go ahead and install.<\/p>\n\n\n\n
    You can include both switches without any issues even if you aren\u2019t on Windows 10 and don\u2019t currently have Pester installed. To validate the version that was installed, you can use Get-Module<\/strong>.<\/p>\n\n\n\n
    Get-Module Pester -ListAvailable<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    <\/p>\n\n\n\n
    On this system there are three versions. Version 3.4.0 was preinstalled with Windows 10. When I first started writing this article, 4.3.1 was the current version, and was installed using the Install-Module<\/strong> cmdlet above. Shortly afterward version 4.4.0 was released, so the following cmdlet was used to update Pester to the most current version.<\/p>\n\n\n\n
    Update-Module Pester -Force<\/pre>\n\n\n\n
    If you only have 3.x installed, you will need to use the Install-Module<\/strong> method, after you have version 4.0 or later installed from the gallery, you will be able to use Update-Module<\/strong> to keep it up to date.<\/p>\n\n\n\n
    You\u2019ll find the code from this section in the file Get-Pester.ps1<\/em> in the author\u2019s GitHub repository<\/a>.<\/p>\n\n\n\n
    Running Tests<\/h2>\n\n\n\n
    Before you start writing tests, you should know how to run them. The Pester module includes the Invoke-Pester<\/strong> function. With it, you provide either the name of a script containing the tests to execute, or the name of a folder. By convention, although not required, scripts with Pester tests should end with .Tests.ps1<\/em>. While not a requirement, you will typically create a tests file for each ps1<\/em> file you have. If you had a file, DoSomeStuff.ps1<\/em>, its corresponding test file would be DoSomeStuff.Tests.ps1<\/em>. This convention allows you to execute all tests in a folder by using Invoke-Pester<\/em> and passing in the name of a directory. It will find and run all files that have the .Tests.ps1 <\/em>extension.<\/p>\n\n\n\n
    <\/a> For this article, all the tests will be stored in the file BasicPester.Tests.ps1<\/em>. You\u2019ll use Invoke-Pester<\/strong> to run this tests file. Store the code below in the script, Invoke-BasicPesterTests.ps1<\/em>, or you can download the file from the GitHub repository<\/a> for this article.<\/p>\n\n\n\n
    $dir = 'C:\\PowerShell\\Pester-Demo'\nInvoke-Pester \"$dir\\BasicPester.Tests.ps1\"<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    Alternatively, you could have used Invoke-Pester $dir<\/strong>, and it would have run all files ending in .Tests.ps1<\/em>, including BasicPester.Tests.ps1<\/em>. Finally, you could have also just run Invoke-Pester<\/em>, in which case it would execute all *.Tests.ps1<\/em> files in the current folder. If your PowerShell session was currently in C:\\PowerShell\\Pester-Demo<\/em>, Invoke-Pester will run all .Tests.ps1<\/em> files in that folder.<\/p>\n\n\n\n
    Now that you know how to run tests, it\u2019s time to start writing them!<\/p>\n\n\n\n
    Your First Test<\/h2>\n\n\n\n
    Take a look at a very simple test.<\/p>\n\n\n\n
    Describe 'Basic Pester Tests' {\n  It 'A test that should be true' {\n    $true | Should -Be $true\n  }\n}<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    Under the hood, Pester commands are really nothing more than PowerShell functions. Thus, the Describe<\/strong> method (aka function) is the initial method called. One thing you\u2019ll notice about Pester, is that it does not follow the naming conventions of other PowerShell cmdlets. Most, even when you author your own functions, use the verb-noun naming convention.<\/p>\n\n\n\n
    The authors of Pester chose to go a different route. Pester uses a language of its own, one meant to make tests more readable. This concept is known as a DSL, or Domain Specific Language<\/em>. With DSLs, a syntax is created that is much more readable and friendlier to the human users. You will find Pester implemented a DSL that is meant to make tests easily read and convey a clear meaning as to what is going on.<\/p>\n\n\n\n
    As noted, a basic Pester test begins with the Describe<\/strong> command. The Describe<\/strong> function acts as a container for one or more tests. After Describe<\/strong>, a text string that describes the tests contained in it. This example has a simple name of Basic Pester Tests<\/strong>. Under the hood, this string is the first parameter to the Describe<\/strong> function in the Pester module.<\/p>\n\n\n\n
    At the end of the line there is a {<\/strong> (an opening squiggly brace). The next line has more code, which continues until you find the closing }<\/strong> (squiggly brace). At first glance this structure resembles other built-in PowerShell commands, such as foreach<\/strong>. This is a bit deceptive, though. What is really happening is that you are defining a script block<\/em> and passing it into the Pester modules Describe<\/strong> function. A script block is PowerShell code that has been defined as an object. The previous code could have been defined like:<\/p>\n\n\n\n
    $scriptBlock = {\n  It 'A test that should be true' {\n    $true | Should -Be $true\n  }\n}\nDescribe 'Basic Pester Tests' $scriptBlock<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    It would work, however, this makes the code more difficult to read and thus should be avoided, at least for your Pester tests. For more information on script blocks, see the About Script Bocks<\/a> article.<\/p>\n\n\n\n
    This does have one other implication you should be conscious of. With a foreach<\/strong> block, you have the freedom to place the opening squiggly brace on the same line as the foreach<\/strong>, or on the next line. Both of these are valid:<\/p>\n\n\n\n
    foreach ($x in $list) {\n  # code here\n}\nforeach ($x in $list) \n{\n  # code here\n}<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    This isn\u2019t allowed with Pester tests, as the script block is a parameter to the Describe<\/strong> function. If the brace was on the next line, PowerShell would not be able to find it and return an error for a missing parameter (the script block). If you really wanted to, you could place a line continuation character at the end, then the opening squiggly brace on the next line. However, this doesn\u2019t aid anything in terms of readability.<\/p>\n\n\n\n
    So now you\u2019ve seen how to call the Describe<\/strong> function, given it a name, and then created a script block to hold one or more tests. A test is defined using the Pester function It<\/strong>. Like the structure of the Describe<\/strong> function, you first pass in a string containing the name of the test. This is followed by a script block that defines the test condition. Save the code from the beginning of this section to your BasicPester.Tests.ps1<\/em> file in the folder you created.<\/p>\n\n\n\n
    For this type of test, you first execute some type of equation, comparison, or function call that results in a Boolean value. This example is simply using the Boolean value of $true<\/strong>.<\/p>\n\n\n\n
    The results of that equation are then piped to the Pester Should<\/strong> function. The first thing to supply to the Should<\/strong> function is a switch that indicates the expected results. The -Be<\/strong> switch indicates that what is being piped into Should<\/strong> needs to equal the value passed as the second parameter. This example is saying the constant $true<\/strong> must equal the $true<\/strong> being passed into the Should <\/strong>function\u2019s second parameter.<\/p>\n\n\n\n
    <\/a><\/a> Execute the test and look at the results. With the Describe<\/strong> example at the top of this section saved in a file BasicPeter.Tests.ps1<\/em>, execute the Invoke-BasicPesterTests.ps1<\/em> file (shown in the earlier section Running Tests).<\/p>\n\n\n\n
    You should see the following output (your output colors may vary depending on your color settings in the ISE or PowerShell console).<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    <\/p>\n\n\n\n
    The first line reports that it is executing all tests in the PS1 file. If you had just called Invoke-Pester<\/strong> without providing a specific file, this would just display the name of the folder passed in (or the current folder if no folder was passed in). The next line, Executing script\u2026<\/em> tells which .Tests.ps1<\/em> file is getting executed for this section of output. This is useful when you are executing multiple test files at the same time.<\/p>\n\n\n\n
    Next, you\u2019ll see the first (and only for this test) Describe<\/strong> block being executed. The Basic Pester Tests echoes back the string supplied as the first parameter to the Describe<\/strong> function.<\/p>\n\n\n\n
    After the first parameter string, you\u2019ll see a +<\/em> followed by the name of the test, the string supplied to the It<\/strong> function. The +<\/em> is the indicator that the test passed successfully! Following is the length of time the test took, 36ms for this example.<\/p>\n\n\n\n
    On the next line is the total run time for all tests, since it only had one test it took 36ms. The last line is a summary, it tells us how many tests passed, failed, were skipped, pending, or inconclusive. Passed and failed are pretty obvious. In a later article you\u2019ll see how to flag tests to be skipped, or put into pending status, as well as what inconclusive results are.<\/p>\n\n\n\n
    \n    
    \n        
    \n            
    \n                
    Automate your SQL workflows with PowerShell and Redgate<\/h3>\n                
    \n                                            With tools like Redgate Monitor, SQL Clone, SQL Change Automation, SQL Data Catalog, and Redgate Flyway, you can monitor servers, create clones, deploy database changes, and more \u2013 all from your PowerShell scripts.                                    <\/div>\n            <\/div>\n                                            Explore the full portfolio<\/a>\n                    <\/div>\n    <\/div>\n<\/section>\n\n\n
    Your Second Test \u2013 Failure Is an Option After All!<\/h2>\n\n\n\n
    What does it look like when your test fails? Modify the original code to add a second test.<\/p>\n\n\n\n
    Describe 'Basic Pester Tests' {\n  It 'A test that should be true' {\n    $true | Should -Be $true\n  }\n  It 'A test that should fail' {\n    $fail | Should -Be $true\n  }\n}<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    The second test in a Describe<\/strong> script block is A test that should fail<\/strong>. Passing in the Boolean fail to the Should<\/strong> function and comparing that to true will of course cause this test to fail. When you run the tests, you\u2019ll see this for our output:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    <\/p>\n\n\n\n
    The second test appears with a \u2013<\/strong> sign, and all in red! This is the indication that the test failed in 13ms. The next line displays the expected result (the result after the Should -Be<\/strong>) and what was actually passed in. A line number and the code that trigged the failure are provided. On the last line of the results for this test, you\u2019ll see the full file name with the test.<\/p>\n\n\n\n
    After this is the total time for all of the tests, then a summary indicating the number that passed, failed, etc. As you can see, the failures are displayed in red letters.<\/p>\n\n\n\n
    More Should than Should Be Allowed<\/h2>\n\n\n\n
    There are actually many variations to the Should<\/strong> function. Another popular one is the -Exist<\/strong> switch. It takes a file name that is piped in and checks to see if it exists.<\/p>\n\n\n\n
    Describe 'should exist test' {\n  It 'Should exist' {\n    'C:\\PowerShell\\Pester-Demo\\Invoke-BasicPesterTests.ps1' |\n      Should -Exist\n  }\n}<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    This can be very useful, especially when testing functions that download or create files. It can also be useful for validating your code. For example, you are writing a module. One of your tests might be to check the existence of your manifest file. The output from the test above looks like:<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    <\/p>\n\n\n\n
    Nice, but remember this is PowerShell! You can actually use PowerShell code as part of the tests. Take a look at this version of the test.<\/p>\n\n\n\n
    Describe 'should exist with variables test' {\n    $someFile = 'C:\\PowerShell\\Pester-Demo\\Invoke-BasicPesterTests.ps1'\n    It \"$someFile should exist\" {\n      $someFile | Should Exist\n    }\n}<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    Here the file being tested for is placed in a variable. This lets you use string interpolation to make the file name part of the name you give to the test. And you can reuse the variable passing it into the Should<\/strong>.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    <\/p>\n\n\n\n
    Now the file name is part of the test name itself. You will know exactly what file name was being tested for, making the results more valuable, especially when you may have a situation with multiple files.<\/p>\n\n\n\n
    Providing Context<\/h2>\n\n\n\n
    Often a Describe<\/strong> block can contain many tests. When there are quite a few, it can be helpful to group related tests into blocks. This is where the Context<\/strong> function comes into play. You can think of a Context<\/strong> as a sub-Describe<\/strong>, it will provide an extra level in the output. In the following code sample, the tests are grouped into Context groups. In addition, you\u2019ll also see some other variations of Should<\/strong>. Finally, for a few of the tests, you\u2019ll condense the script blocks being passed into the It<\/strong> functions onto a single line. Just to demonstrate, it isn\u2019t always necessary to break them up across multiple lines.<\/p>\n\n\n\n
    Describe 'Grouping using Context' {\n    Context 'Test Group 1 Boolean Tests' {    \n      It 'Should be true' { $true | Should -Be $true }\n      It 'Should be true' { $true | Should -BeTrue }\n      It 'Should be false' { $false | Should -Be $false }      \n      It 'Should be false' { $false | Should -BeFalse }      \n    }\n    Context 'Test Group 2 - Negative Assertions' {    \n      It 'Should not be true' { $false | Should -Not -BeTrue }\n      It 'Should be false' { $true | Should -Not -Be $false }\n    }\n    Context 'Test Group 3 - Calculations' {    \n      It '$x Should be 42' {\n        $x = 42 * 1 \n        $x | Should -Be 42\n      }\n      \n      It 'Should be greater than or equal to 33' {\n        $y = 3 * 11\n        $y | Should -BeGreaterOrEqual 33\n      }      \n      It 'Should with a calculated value' {\n        $y = 3\n        ($y * 11) | Should -BeGreaterThan 30\n      }      \n    }\n    Context 'Test Group 4 - String tests' {\n      $testValue = 'ArcaneCode'\n      # Test using a Like (not case senstive)\n      It \"Testing to see if $testValue has arcane\" {\n        $testValue | Should -BeLike \"arcane*\"\n      }\n    \n      # Test using cLike (case sensitive)\n      It \"Testing to see if $testValue has Arcane\" {\n        $testValue | Should -BeLikeExactly \"Arcane*\"\n      }\n    }\n    Context 'Test Group 5 - Array Tests' {\n      $myArray = 'ArcaneCode', 'http:\/\/arcanecode.red', 'http:\/\/arcanecode.me'\n      It 'Should contain ArcaneCode' {\n        $myArray | Should -Contain 'ArcaneCode'\n      }\n      It 'Should have 3 items' {\n        $myArray | Should -HaveCount 3\n      }\n    }\n}<\/pre>\n\n\n\n
     <\/p>\n\n\n\n
    Whew, that\u2019s a lot of tests! In fact, it won\u2019t be at all uncommon for your tests files to contain many, many tests. Indeed, the number of lines in your test scripts will often far exceed the number lines in the code being tested. Before analyzing the sample, look at the effect the use of Context had on the output.<\/p>\n\n\n\n
    \"\"<\/figure>\n\n\n\n
    <\/p>\n\n\n\n
    The use of Context<\/strong> broke the results into nice, easy to read sections. Rather than just line after line of tests, you can easily see the results broken into logical groups. Now look at some of the tests that were performed.<\/p>\n\n\n\n
    Test Group 1 resembled tests performed in the opening section of this article. However, you can shortcut the use of Should -Be $true<\/strong> by using the -BeTrue<\/strong> switch. Likewise, there is a -BeFalse <\/strong>switch. In Test Group 2, you\u2019ll see that Pester also supports negative assertions. Simply add a -Not<\/strong> switch prior to the call to the Be<\/strong> switch, as was shown with Should -Not -BeTrue<\/strong>.<\/p>\n\n\n\n
    In Test Group 3, you\u2019ll see how Pester handles calculated values. In addition to the BeGreater…<\/strong> switches there are also BeLess…<\/strong> versions of the switches. In the last example in this section, an actual calculation is piped into the Should<\/strong> function. When doing so, you must enclose your entire calculation in parenthesis. This forces PowerShell to do the calculation, then pass the result into the Should<\/strong>.<\/p>\n\n\n\n
    Pester also supports testing of string values, as demonstrated in Test Group 4. A simple test is to use the like<\/strong> operator under the covers for wild card matches, with one version for case insensitive and another for case sensitive. Although not shown, you can also use the Be<\/strong> switch for string comparisons.<\/p>\n\n\n\n
    In the last test group, number five, contains some tests for arrays, ascertaining if an array contains a certain value as well as ensuring the array has a specific count.<\/p>\n\n\n\n
    While these are some of the most common Should<\/strong> tests you can perform, it is by no means a comprehensive list. There are switches for working with files, regular expressions, and more. You can find a complete list at the Pester wiki<\/a>.<\/p>\n\n\n\n
    Summary<\/h2>\n\n\n\n
    This article covered the basics of Pester. Using just what you\u2019ve learned here, you can begin testing your PowerShell scripts. Don\u2019t be fooled though, Pester provides an incredibly rich framework for testing. Future articles will cover such things as:<\/p>\n\n\n
    \n