Pester VS bicep

Pester is what's used for most Powershell testing. While it has some pretty amazing features, it does have issues with .NET class method mocking and sometimes scope can be weird. Here's a simple example:

This is the fun that is Powershell mocking, or at least the form that someone completely new to Powershell would write. One thing I must say is that Pester's mocking capabilities are quite easy to work with. It reminded me of pytest mock patching, only well, simpler. Most of the time spent fighting tests was due to the nuances of pipeline flow. For example, you can see that your mocked method was called X many times through something like this:

The folder blocked all users from reading the files so if you open up the files it looks empty, even tho you have show hidden files turned on. You can't delete it since it says that you need access from TrustedInstaller. This is cleaver by the hacker since trusted installer is actually the name of a windows feature. HOW-EVER by using the command line I found out that the folder contains framework like these two. https://github.com/d1pakda5/PowerShell-for-Pentesters https://github.com/pester/Pester

I'm really surprised that nobody in this thread has mentioned Pester. PowerShell has its own automated unit testing framework that is incredibly versatile. You do need to know PowerShell in order to really make it shine, but if there are some simple tests that your class requires such as "make sure this value conforms to this regex value", Pester is pretty easy to pick up and utilize.

Once you start building code/scripts that are used consistently, consider adding Pester testing to your work. Most sysadmin managers may not get it, but if you're talking to dev managers, they'll absolutely get the importance of unit testing and why it's a good tool to have. Again, down the road. Learn the basics first.

Finally, the Pester testing framework, which ships with Powershell, is a great way to ensure your code actually does what it's meant to do.

Pester GH page

I thought it was a good idea, but Bicep did not agree. I have submitted a proposal to the Bicep team for how this can be allowed. Vote for this issue if you agree!

Bicep has limitations which makes it non-declarative even though it is marketed as declarative: https://learn.microsoft.com/en-us/azure/azure-resource-manag...

MSFT is trying to add features to make this better, but it is not in production yet: https://github.com/Azure/bicep/issues/10460

Additionally, Bicep does not support interacting with Azure Active Directory: https://github.com/Azure/bicep/issues/7724

So it really is not very useful. Terraform is better in almost every single conceivable way.

Github: https://github.com/Azure/bicep/issues/9569

Since its launch Bicep has become popular within the IT community. You can find blog posts, tweets, conference sessions, and plenty of interaction on the official Bicep GitHub space. Bicep became production ready at v0.3. It is supported by Microsoft Support Plans.

Please give Azure Bicep a try. You get a really simple experience with all the benefits of using the platform native capabilities https://github.com/Azure/bicep

I was on the bicep call last month but that doesn't mean I didn't miss the announcement, it looks like they are getting close though - https://github.com/Azure/bicep/issues/8598

Bicep, the open source project used by Visual Studio Code to extend its capabilities, has finally arrived in Visual Studio, enabling users of Microsoft’s flagship IDE to use some of Bicep’s most popular features in the same program they have been using since they were introduced to it — in other words, Visual Studio itself.

In addition, check the similar issue on GitHub.

There is an ongoing thread here https://github.com/Azure/bicep/issues/1853