During the summer, someone asked the following question on the WSUS patchmanagement.org mailing list.
I replied and immediately thought that Pester would do the job and quickly showed how he could test if he can connect to the console.
I’ve actually more than a WSUS server to manage. So, I started separating the environmental configuration data from the pester tests code almost the same way Mike F. Robbins did in his recent post where he goes far beyond to what I did.
I think it’s a great idea and here’s what I did in my case to monitor my WSUS server operational status.
To get started, I copied the Pester module on my WSUS server, imported the module and did in the ISE:
# helper to create the required files and folder if not present
New-Fixture -Path ~/Documents/Pester -Name Test-WSUS
# Put the config data into that file:
# Put the pester code into that file:
After the first 3 commands, here’s what the ISE console looked liked
The first file Test-WSUS.ps1 looks like this by default.
It will be used to store my configuration data.
The second file Test-WSUS.Tests.ps1 is where I’ll write the pester tests code
After editing the 1rst file Test-WSUS.ps1 like this:
(fake data in this case)
…and the 2nd file Test-WSUS.Tests.ps1 like this:
…I’m actually ready to assess the operational readiness of my WSUS configuration by using the following cmdlet:
Invoke-Pester -Script ~/Documents/Pester/Test-WSUS.Tests.ps1
I still feel like a Pester newbie but no doubt that Pester rocks 😎