I have been using Pester and integrated it with my dxExchange.WebServices module following HDD/TDD practices. I have wanted to start incorporating Pester testing into cloud configuration validation and management for some time, but never really got around to it.
A couple of weeks ago, I participated in a Network DevOps course facilitated by Nick Russo on Safari Books Online. It was a great course that focused on theory, but used GitHub, Ansible, and Travis to illustrate how to manage Cisco networking devices. It was a good course and it rekindled this desire to do some of these things with Pester.
I wrote the xAzureAD.DirectorySetting module in Q4 2017 because I was frustrated with how the basic actions to limit Office 365 Groups creation to members of a specific group essentially required background as a developer. It really should be a matter of running a simple “Set” command with a parameter and providing the group name. That is what the module offers.
I had not used the module for some time and was surprised that it still worked exactly as expected and even still requires the AzureADPreview module rather than working with the AzureAD module.
I set about creating a quick mock up of a Pester test to validate the settings:
In addition, a CSV file with the expected values is needed and should be loaded to memory. The comments at the beginning of the Gist explain the process to get the initial values. The code also assumes that you are authenticated to Azure AD with the necessary rights.
Here is the output:
This simply validates that the settings have not changed. To further refine this, it could be updated to also update the configuration to match the expected values if there has been configuration drift or an initial setting or change that is intended.