As we all try to do more with less with automation, we sometimes get to a point to where we've got a new problem. We're now running so many scripts and processes that, in the end, we're not sure what "done" looks like.

If we're running a user provisioning script that creates an AD (Active Directory) user, an Exchange mailbox, a home folder, etc.; how do we truly know that script did everything it was supposed to?

We don't. We can notice that there wasn't an error thrown and also spot-check things afterward. But if the script is covering 1,000 users, there's no way that's going to be feasible. We need to automate testing too!

What is Infrastructure Testing?

One way to automate this kind of testing is with what is loosely called infrastructure testing. What is infrastructure testing? It means any code that reads configuration values from various things in the IT environment and compares them to expected values. Some examples: "Was that AD user created with the right attributes?", "Is port 80 responding on my web server?", "Is the DHCP service running?", etc.

The infrastructure testing discussion is much bigger than we have time for in a single article but I can give you a head start. As you begin writing these tests you'll start to notice patterns; you'll start to realize that you're writing the same kind of code over and over again just applied to different infrastructure elements. Rather than copying and pasting all the time you can share this code in the form of a PowerShell script or function. Let's go over a couple types of testing scripts that I use to help me ensure my infrastructure is configured appropriately.

Testing a Network Port

One typical example of an infrastructure test is testing a network port. Since all network services open up and listen on a particular port, a real test of that service is "up" or not is to confirm that a specific port is available to remote computers. To build this type of test though requires a fair amount of knowledge about TCP/UDP stacks and .NET but luckily you can use an existing script from the community called Test-NetworkPort.ps1. This script can be downloaded from the PowerShell Gallery:

Install-Script -Name Test-NetworkPort

Once downloaded, simply call it by using Test-NetworkPort.ps1. Depending on if the port is listening or not this script will return True or False. You can explore other parameters this script has by reading the help associated with it.

PS > Test-NetworkPort.ps1 -ComputerName DC -Port 389
 True

Testing DNS Name Resolution

Here's another good test to use. When bringing up a new machine whether relying on dynamic DNS to register the name or if you're creating a DNS record explicitly, you're going to need to ensure its name can be resolved. With PowerShell, we can use a script that attempts to resolve a particular name and return True or False if it can be resolved or not.

As with our port testing example, we can also download this script from the PowerShell Gallery as well.

Install-Script -Name Test-DnsNameResolution

When the download has completed, simply call Test-DnsNameResolution.ps1 with the Name and the DNS server you'd like to query.

PS> Test-DnsNameResolution.ps1 -Name DC.mylab.local -Server DC
 True

These are just two examples of wrapping up common code into scripts. These scripts can even be quickly turned into functions and included in a PowerShell module too, but we'll save that for another day.