One of the huge benefits of attending in-person technology events is getting to network with others. While at the MVP Summit last month I had a chance to demonstrate some of my PowerShell code and Pester tests to Jim Truher. I was developing the code and tests for a session to present for the PowerShell Virtual Chapter of SQL PASS (the code and a video of that presentation can be found here).
I recently presented a session on “Automate Operational Readiness and Validation Testing of SQL Server with PowerShell and Pester” for the PowerShell Virtual Chapter of SQL PASS. The video from that presentation is now available: Both the code and slide deck from the presentation can be found in my presentations repository on GitHub. µ
Do you ever feel like you’re writing the same operational validation or readiness test over and over again? I’m not sure about you, but I don’t like repeating myself by rewriting the same code because it creates a lot of technical debt. There has to be a better way . Why not take the same thought process from DSC (Desired State Configuration) and separate the environmental portion of the code from the structural portion and apply it to operational tests so the same or similar code isn’t repeated over and over again?
I’ve recently been working with Altaro VM Backup and I must say that I’ve been very impressed with the ease and simplicity of the product. The back-end portion of the product can run on a virtual or physical server with or without the GUI (Server Core is supported). It can backup to just about any type of drive (local disk, UNC path, USB drive, etc). It doesn’t require SQL Server. In my environment, adding a Hyper-V server (running Windows Server 2012 R2) installed a service on the Hypervisor, but did not require a reboot.
We’ve all heard that TDD (Test Driven Development) means that you write unit tests before writing any code. Most of us are probably writing functional or acceptance tests after the fact because the idea of Test Driven Development isn’t clearly defined, at least not in my opinion. I originally thought it meant to write thorough unit tests to test all functionality for a specific piece of code such as a PowerShell function from start to finish before writing any of the production code for the function itself.
I recently wrote a Pester test that performs some basic operational validation (smoke tests) of SQL Servers. I’ve previously written similar tests as functions as shown in my Write Dynamic Unit Tests for your PowerShell Code with Pester blog article, but I decided to write this one as a script with the naming convention that seems to be recommended. The name of this particular test is Validate-MrSQLServer.Tests.ps1. You’re probably thinking Validate isn’t an approved verb and you’re right, but this isn’t a function, it’s a script.
I wrote a blog article on: PowerShell Script Module Design: Placing functions directly in the PSM1 file versus dot-sourcing separate PS1 files earlier this year and I’ve moved all of my PowerShell script modules to that design and while today’s blog article isn’t part of a series, that previous one is recommended reading so you’re not lost when trying to understand what I’m attempting to accomplish. Most unit tests that I’ve seen created with Pester for testing PowerShell code are very specific, the tests generally have hard coded values in them, and live in source control along with the code that they’re designed to test.
If you haven’t seen the Operation Validation Framework on GitHub, it’s definitely something worth taking a look at. This framework allows you to write Pester tests to perform end-to-end validation that a system is operating properly. Pester is typically used to perform test driven development or unit testing on your PowerShell code, but in this scenario it’s used for operational testing. You need to have Pester installed, but if you’re running Windows 10 then you already have Pester.
I recently published a blog article on unexpected case sensitivity in PowerShell. An example in that blog article uses the contains method which is indeed case sensitive. One of the workarounds that I demonstrated was to convert whatever the user entered to upper case using the ToUpper() method. One of the reasons I like blogging is that many times there are things that I may not have considered and sometimes things that I wasn’t even aware of so in addition to sharing my knowledge with others, I often times learn in the process based on the feedback I receive about my blog articles and this was one of those times.
How do you normally write your PowerShell code? Your answer is probably like mine and most other IT pros. You have a task that you need to accomplish and instead of performing a clicker-size in the GUI whenever that task is required to be performed, you write a PowerShell one-liner, script, or function to automate that task. You test it a little to make sure there aren’t any major issues and you implement it, moving on to the next task.