A lot of my Powershell code interacts with databases and servers. Sometimes I’m grabbing a connection string, other times I’m check-pointing a long operation. When writing Powershell code that interfaces with databases, there’s usually a lot to test for. Well, it’s surprisingly simple to mock up SQL results using Pester.
This is a how-I-do post about organizing Powershell code. As the title suggests, this is simply how I do things at this particular moment.
Is it just me or are there actually more uses for custom Powershell modules in the day to day operations? From pure laziness (not wanting to open up SQL Server Management Studio just to grab a status/field/connection string/<fill in blank>) to environment setup (restoring databases to staging environments, provisioning machines, deploying code). We’re even using a Powershell module to post Slack messages! I probably commit code to at least one Powershell module each week. Even better is the fact that I’m usually not the only one committing Powershell code to our company GitHub repositories.
The light at the end of that tunnel requiring a bug fix in a large Powershell script –with zero unit tests (of course) — may finally be within sight.