In my previous blog post, I demonstrated how to use PSRule to validate Azure API Management policies by defining several custom rules, each with specific logic. As a fan of Test Driven Development, I created these rules following a test-first approach. In this post, I’ll walk you through how to write automated tests for these PSRule rules using Pester, a popular testing framework for PowerShell.
I’ve been working with Azure API Management for a while now, and one of the challenges I’ve faced is finding a reliable way to validate the XML policies I write. While tools like SonarQube are excellent for code quality checks, they don’t support the specific checks required for Azure API Management policies. In this blog post, I’ll demonstrate how to use PSRule to validate your Azure API Management policies effectively.
In this blog post, we’ll explore how to use the IParsable<T> interface to build a generic Reqnroll value retriever and comparer. We’ll start by creating custom value retrievers and comparers, then develop a reusable solution with generics, and finally, we’ll use reflection to make it even more generic. (This solution also works for its predecessor, SpecFlow, when using .NET 7 or higher.)
When you have a string value in Bicep with multiple placeholders that you want to replace, it can be tricky to find a good way to do this. In this blog post, I will show you how you can replace placeholders in a string with a couple of user-defined functions.
When deploying Azure resources, it’s a good practice to apply a naming convention to your resources. This will help you to identify the purpose of the resource and the environment it belongs to. In this blog post, I will show you how to apply a naming convention using Bicep user-defined functions. This post also includes a short introduction to the (experimental) Bicep Testing Framework.
In this third post on working with client certificates in Azure API Management, we’ll focus on securing backend connections with mTLS. We’ll deploy two API Management instances. The first will serve as the backend and require a client certificate for authentication. The second will act as the client. We will call the client using TLS, and it will, in turn, connect to the backend using mTLS.
