When unit testing with Pester, mocking is pretty much unavoidable, especially for code related to infrastructure, configuration, or deployment. We don’t want our unit tests to touch files, databases, the registry, and not to mention the internet, do we ?
As you probably already know, when writing a DSC configuration, separating the environmental data from the configuration logic is a best practice. So all the environment-specific data gets stored in separate (typically .psd1) files. If you work with PowerShell DSC at medium-to-large scale, you (ho...
As you already know if you have read this or this, I’m a big fan of PSScriptAnalyzer to maintain a certain coding standard. This is especially powerful inside a release pipeline because this allows us to enforce that coding standard.
Nowadays, many IT shops look a lot like the first few pages of The Phoenix Project : lack of automation and communication which leads to manual and unpredictable deployments, which in turn, leads to firefighting.
Coding, especially in PowerShell, is not about remembering the exact syntax of how to do something, it is more about knowing how to try things out and to get the information we need to do whatever we need to accomplish.
I read Jeff Hicks’s article about “Dancing on the table with PowerShell”. The content is really quite fascinating (go read it !), but I got hung up on something.
Recently, I had to roll out an upgrade of our software for a customer. The upgrade failed for about 80 client machines (out of around 400). There was a lot of head-scratching and quite a few :
Unit testing PowerShell code is slowly but surely becoming mainstream. Pester, the awesome PowerShell testing framework is playing a big part in that trend.
As you probably know, PSScriptAnalyzer is a static code analysis tool, which checks PowerShell code against rules representing best practices and style guidelines. This is a fantastic tool to set coding style and quality standards, and if we want to, we can easily enforce these standards within a ...
When writing a DSC configuration, separating the environmental data from the configuration logic is a best practice : it allows to reuse the same logic for different environments, for example the Dev, QA and Prod environments.