As we all try to do more with less with automation, we sometimes get to a point 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, or a home folder, 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 use test automation, 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 of infrastructure testing include:
“Was that AD user created with the right attributes?” “Is port 80 responding on my webserver?” “Is the DHCP service running?”
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 repeatedly writing the same kind of code, just applied to different things. 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 of common examples of 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. Because all network services open up and listen on a particular port, a real test of if that service is “up” or not is to confirm that a specific port is available to remote computers. To build this test, though, requires a fair amount of knowledge about TCP, UDP, and .NET. Luckily, you can use an existing script from the community called Test-NetworkPort.ps1. This script can be downloaded from the PowerShell Gallery by running Install-Script -Name Test-NetworkPort.
Once downloaded, simply call it by using Test-NetworkPort.ps1 and pass a computer name and port to test.
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 via Get-Help Test-NetworkPort.ps1.
This script performs a test on the infrastructure listening on a particular port.
Testing DNS Name Resolution
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, you 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 via 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.
If the script returns True, the DNS server DC can resolve the name of DC.mylab.local. If not, it would have returned False.
Conclusion
The examples provided here are just two amongst thousands. The point of this article isn’t to show you you how to to perform infrastructure tests but more to guide you on creating your own.
To create well-developed infrastructure tests requires first defining what it means to be “up” or “expected”, building a PowerShell script to find the current and expected state, and to make a decision from there.
Don’t continue to manually confirm your infrastructure is working as you expect. Get to building some PowerShell scripts and automate those mundane processes for you!