Separating Environmental Code from Structural Code in PowerShell Operational Validation Tests

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

An article that I wrote for PowerShell Magazine on “Eliminating Redundant Code by Writing Reusable DSC Configurations” provides a good overview of the thought process that I’m going to apply to operational tests.

The following example shows a function that is used to perform validation of multiple environments for a specific application on one or more servers:


Separating the environmental portion of the test is simple enough and finding items that might need to be changed is now much easier than having all of the environmental specific items buried in one huge test.

The structural portion of the test itself is now much more condensed and concise along with being reusable:


Specific modifications have been made to the code shown in these examples so that the actual application and service names aren’t disclosed.

Since I haven’t seen anyone else separate environmental code from structural code for operational testing before, I would like to know what your thoughts are on this subject and if you can think of any problems that it may create that I may not have considered.



  1. Mat Czerniawski

    I’ve been working on similar aspect as you recently. What I want ot achieve is to hold configuration data in separate files (.json format) for each functionality – basic VM/box configuration, customized vm specific configurations, general service configurations (like sql) an specific service configurations. This way each part can be managed by a different team and stored in GIT/SVN. From there deployment can be done (through CI/CD/ Powershell/Scripts/DSC or manual) and tests (for general and specific settings alike). Tests could be run periodically, after each deployment or reboot.
    New ideas


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: