Recently, I started using Pester. I was thinking about how this testing framework can be useful to improve the ARM Templates deployment.
Azure has a cmdlet “test-AzResourceGroupDeployment” to validate ARM Template without deploying it. This cmdlet seems good, but is it enough ? Imagine that your ARM Template won’t deploy the wanted resources. What if someone,somehow modified your template, how can you ensure that your template won’t deploy something you don’t need ? Even if the ARM has been deployed successfully, nothing can ensure that your services has been correctly configured.
The solution is testing the ARM Template using Pester which is a testing and mocking framework for Powershell. Using this solution, we will be able to prevent some configuration mistakes. So we can test our template without deploying it and we will have an idea about how the ARM Template will react when we run “new-AzResourceGroupDeployment”.
Common ARM Templates Validation
There is some common ARM Templates tests to perform. These tests can be customized, you can also add your own tests. Before going in deep in these tests let’s talk about “Pester”.
As I told you before, Pester is a testing and mocking framework for Powershell. It allows us to write tests that we can perform. So then when we make changes we can ensure that it will work in production.
Unit tests must be human readable. So each tested block must be well named and described. That’s why Pester has a kind of scoping blocks :
- Describe : It describes a group of tests. Any Pester file must contain at least one “Describe” section. Any other Pester command must be inside it;
- Context : It is not a must but a nice to have. It’s an optional subgroup inside of “Describe”;
- It : This is a single test case. Running Invoke-Pester, each “it” block will or pass or fail.
It also has (for sure :D) an assertion. You are asserting something true.
- Should : It is an assertion. It has some operators such as Be, BeExactly and Throw. (Be is a non-case sensitive, if you want a case sensitive you must use BeExactly).
Let’s go back to ARM Templates. As I said there is some common tests to perform using a combination of the commands that I’ve just wrote. These tests are about file validation and content validation.
In the following example, I will test a “Storage Account” ARM Template. The goal is to verify the file and its content.
About the file validation, I will :
- Check if the file exists;
- Check if it is a valid JSON.
About the content validation, I will :
- Check if it contains the schema, contentVersion, outputs, parameters and resources;
- Check if the template will deploy the expected resource (in my case it is a Storage Account).
We have a lot of benefits using these tests. First of all, I am sure that my template will deploy only the resource that I want (Storage Account) and it contains the elements which are required. Also, I am sure that the file exists and it is a valid JSON !
If someday, somehow, someone changes the ARM Template, if he broke something that I’ve built, the deployment won’t pass because the tests will be red.
Use Pester with Azure DevOps to test an ARM Template
Go to the “MarketPlace” and look for Pester Test Runner. Install it.
Then look for the yml file of your build CI and add the Pester Test Runner.
Then you should see :
- task: Pester@8
If you run the build, you must see the results of your tests.
If your tests are green then the build will be green so you can deploy your ARM Template.
This was just some examples about tests that you can accomplish using Pester. Imagine how professional it is, if you can control your infrastructure before its deployment !