PowerShell How-To

How To Use the PowerShell Operational Validation Framework

The tool simplifies and keeps you organized when testing.

• By Adam Bertram
• 11/17/2016

When building PowerShell tools, I hope by now that testing that script or module is in your repertoire. Testing is necessary to ensure that the code does what you would expect. Proper testing has different "layers" from unit, integration and acceptance tests. Each examines a particular component and result of your PowerShell code. We don't be going over each of these layers in this article but will be focusing on a combination of integration and acceptance testing.

Integration and acceptance testing can be thought of ensuring the code changes the things in the environment, and it meets the end requirements. Rather than testing what the code looks like, integration and acceptance testing tests environmental change. For example, when a PowerShell script executes to create an IIS Web site, you expect a Web site to be created, and that site successfully serves up one or more Web pages that return HTTP/200 when requested. Integration and acceptance testing are industry wide terms, but Jim Truher of the PowerShell team decided to create a framework around Pester that adopts this environment testing pattern called the Operational Validation Framework (OVF).

Let's dive into OVF and see what it can do and how it can ensure the code you write actually accomplishes the end goal. To get started, please download the OVF module from Github and place it in any folder in $Env:PSModulePath  (also, ensure that you have Pester installed).

Since OVF sits on top of Pester, we'll first need to build some traditional Pester tests for OVF to read. I'll create a few that ensures my IIS Web server is listening on port 80, and an index.htm file exists in the Web root.

describe 'IIS Website' {

  it 'is  listening on port 80' {

  Test-NetworkPort  -ComputerName MEMBERSRV1 -Port 80 | should be $true

  }
            it 'the  index.htm page is in the webroot' {

  Get-Item  \\MEMBERSRV1\c$\inetpub\wwwroot\index.htm -ErrorAction SilentlyContinue |  should not be $null

  }

  }

In this example, I'm using the Test-NetworkPort function available on Github. I'll now run this with Invoke-Pester and see what happens.

Invoke-Pester C:\IISWebSite.Tests.ps1

It looks like I've got an index.html file missing. That's OK for now. Let's now see how to wrap this test with OVF. OVF seems to be built with modules in mind, so I'm going to create a fake module and build the appropriate folder structure. Maybe I have a module called MyWebsite. If so, I'd create a Diagnostic folder with two subfolders therein; Simple and Comprehensive. These will hold different kinds of tests. Since our tests are simple, I'll place my Tests fiPowerle in there.

mkdir "C:\Program  Files\WindowsPowerShell\Modules\MyWebSite"

  mkdir "C:\Program Files\WindowsPowerShell\Modules\MyWebSite\Diagnostics"

  mkdir "C:\Program  Files\WindowsPowerShell\Modules\MyWebSite\Diagnostics\Simple"

  mkdir "C:\Program  Files\WindowsPowerShell\Modules\MyWebSite\Diagnostics\Comprehensive"

mv C:\IISWebSite.Tests.ps1 "C:\Program Files\WindowsPowerShell\Modules\MyWebSite\Diagnostics\Simple"

Now that OVF recognizes the folder pattern, I don't have to specify the path at all. I can simply run Invoke-OperationValidation, and it will automatically pick up every test file I've created.

Invoke-OperationValidation

OVF also allows you to run a command to find all of the tests available to you. This is a nice feature so that we don't have to go browsing through different folders to find Pester tests.

Overall, in my experience, OVF just reads your Pester tests, provides a friendlier output and allows you to organize the tests a little better. In this author's opinion, just using Pester and its output and building your own tools would be a better option as we each have unique testing needs. While OVF is an excellent idea, it needs a lot more work to make it a great module.