Using Pester to test NIC settings

Make sure to create a folder that is version control in your computer.

Now use new-fixture cmdlet this cmdlet will create the .ps1 script and then it will create Tests.ps1 where all test instructions will be held

The .ps1 file it has a regular function, on the other hand .tests.ps1 looks completely different lets take a look.

Now to make sure  the test runs you need to run the cmdlet invoke-pester and the path of the folder. In this case the test is going to be skipped because we have not written any yet. Also keep in mind the execution policy should be set to other than Restricted, I am using RemoteSigned.

The first test is to make sure a network adapter called ‘Wi-FI’ is present. For this you can use the Get-NetAdapter cmdlet. The code will look like this

It is time to test but in my case the test is going to fail. I do have a NIC called “Wi-Fi” but i also have a network connection called “Bluetooth Network Connection”. So unit test only ran on the first NIC and failed.

In order to avoid this problem change the function to only return the name.

Now if we run the test again it will fail. If you look at error below. The name that is expecting is “Wi-Fi”but is getting “name=Wi-Fi”

So the way to fix this is to change the function and make sure only the nic name is pass to the unit testing

(Get-NetAdapter | Where-Object { $_.Name -eq ‘Wi-Fi’}).Name

Now if we run the test it will pass

Usually when deploying servers you want to make sure all the settings are correct. One of the most  overlook settings on a server are the NIC settings.  You want to make sure the buffer size is  correct, make sure RSS is enabled,NIC speed is correct, Full Duplex is enabled, etc. Let me show you how you can accomplish this

You will see the code from gist at the end of the post. The main key points here are that you can pass static and dynamic variables to the script.  You should write unit testing scripts as dynamic as possible so they can be reused any where in your environment.