If you’re interested in a free day of PowerShell training, there are numerous sessions on different topics in the dedicated PowerShell track at SQL Saturday #628in Baton Rouge, Louisiana this Saturday, July 29th. I’ll be presenting a session on how to “Automate Operational Readiness and Validation Testing of SQL Server with PowerShell and Pester”. ](/images/2017/07/sqlsatbr2017.jpg)Here’s a little information about what you can expect from my session: Automate Operational Readiness and Validation Testing of SQL Server with PowerShell and Pester How do you know whether or not all of the SQL Servers in your environment are configured based on your organizations standards?

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. µ

I’ll be presenting a webinar on how to “Automate Operational Readiness and Validation Testing of SQL Server with PowerShell and Pester” for the PowerShell Virtual Chapter of SQL PASSon Wednesday, November 16th at 11am CST. ](/images/2016/11/psvcsqlpass111616.pngpsvcsqlpass111616)How do you know whether or not all of the SQL Servers in your environment are configured based on your organizations standards? How do you know whether or not they are all operating properly when maintenance is performed on the systems in your environment?

I’ve previously published articles on separating environmental code from structural code for both DSC (Desired State Configuration) and Operational Validation or Readiness Tests. This article picks up where I left off last week in Separating Environmental Code from Structural Code in PowerShell Operational Validation Tests. As many existing open source PowerShell functions as possible have been used in the examples shown in this blog article instead of re-inventing the wheel and rewriting everything from scratch.

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 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.