During the January Bicep Community Call, the team showcased the new stdin/stdout functionality added to bicep console in version v0.40.2. Someone demonstrated how an AI agent can test Bicep functions using this feature, and at that moment, it hit me:
We can use this to unit test our own Bicep functions locally.
Let me show you how.
Bicep Console (experimental): A Quick Recap
The Bicep console is an interactive Read–Eval–Print Loop (REPL) environment for executing Bicep expressions.
A simple example:
Almost every Bicep function is supported, and you can work with variables as well.
Bicep Console With stdin/stdout (also experimental)
Starting with version v0.40.2, the Bicep console now supports stdin and stdout, which opens the door for automation and scripting.
Quick demo:
And honestly, this is everything we need to start locally unit testing Bicep functions.
More info about this can be found in the release notes: https://github.com/Azure/bicep/releases/tag/v0.40.2
Unit test
Let’s say we have the following function we want to test:
https://gist.github.com/LaurentAerens/b9ed83121a47777df73c80efd5facacb
We already know a few things about this function:
- isValidEnvironment(‘dev’) → true
- isValidEnvironment(‘acc’) → false
We can capture these expectations in a simple JSON test file:
Now let’s automate this with PowerShell.
The PowerShell Flow
1. Extract the function from the Bicep file:
2. Append the function call:
3. Pipe everything into the Bicep console:
4. Add ~800 lines of code to do the assertions, make it look fancy, run everything in parallel, and voilà —
you now have a unit testing framework for Bicep functions
But… Why Would You Do This?
Good question. You might think:
“If my function is wrong, the deployment will fail anyway. Why do I need a test framework?”
And to an extent, you’re right. Most Bicep functions today are small, simple, and written for a single project or customer.
But imagine a world where:
- we build reusable function libraries,
- functions become more complex,
- and every function comes with solid unit tests.
This would enable true test‑driven development for Bicep, making Infrastructure‑as‑Code feel much more like regular code development.
For example, I found this neat function online that checks whether subnets overlap:
https://gist.github.com/JKerens/3d624295bf904945959ba4fac28a40b3
It’s small, but a great start toward general-purpose Bicep function libraries.
So naturally, I wrote tests for it:
And of course, everything works!
Thanks for Reading!
Thanks for taking the time to read my blog about this idea and how we can make IaC feel even more like real software engineering. I’m excited to see what the community will build as Bicep keeps evolving.
My still very experimental unit test framework:
Subscribe to our RSS feed