Unit tests versus integration tests in Pester
To perform a complete Pester test of PowerShell code requires a few different “layers.” These layers test various functional aspects of the code. In this article, I’ll be discussing two of those layers: unit tests and integration tests.
When considering “infrastructure code” or the code that automates infrastructure components like PowerShell in the Windows world, the general purpose is to change the state of some environmental components, like a virtual machine, a file, a registry key, a certificate, etc.
If you’d like to confirm that your code actually changed something in the environment, you’d create an integration test. An integration test actually goes out and reads whatever item your code was supposed to have changed and compares that value against an expected value. If your code was meant to create a VM, an integration test actually executes your code and then immediately confirms that the VM was created in the correct manner.
Getting more granular is a unit test, which confirms correct code execution. It is not aware of the environment at all. A unit test confirms that the code ran as you expected it to run. Whether it actually changed anything in the environment is up to the integration test. A unit test confirms your code attempted to create that file in an expected path, that VM with a particular name, or that local user account with a certain description. Unit tests ensure the code you expect to run executes and follows the pattern you intend it to.
It hasn’t been until recently that system administrators and DevOps professionals have needed to define these types of tests in traditional scripting languages. But nowadays, some of this scripting code has become just as important as the production code it supports. This has led to lots of newer testing frameworks. In the Windows ecosystem, that scripting language testing framework is Pester…
Read the full article at 4SysOps.