Back to Blog

Eric Wright

Ops are from Mars, Devs are from Venus: Falling in Love with Test-Driven Development

Wresting Ready Queue: Spock is to Devs as Scotty is to OpsIn Steven’s recent article, we were introduced to the Test-Driven Development (TDD) concept from the Dev perspective. This is a very powerful tool in the toolkit of a development team, but we also know from what Steven noted is that this is a key component to enabling a DevOps culture in your organization. We’ve visited a number of back and forth topics from the Dev and Ops perspective, so this is an ideal one to keep that conversation going.

In the past, I’ve written on something I called TDI, or Test-Drive Infrastructure. The concept of using TDD methodologies for infrastructure components is not new, but it is new to many organizations that come from the traditional IT operational model.

Test-Driven Development is a powerful enabler for consistent and reliable development practices. This creates a very important comfort with the operations teams because of that consistency and reliability. By ensuring that the behavior of the application code, we remove some of the variables when moving from development to test, to QA, and ultimately to production.

What we are missing still though, is the next advancement for us to create a full end-to-end comfort and consistency by embracing the very same practices on the infrastructure side. This is where we start to expand on the concepts from the introductory article.

Configuration Management and Test-Driven Development

On the infrastructure side, we have something that is making its way into many organizations called Infrastructure-as-Code. This is the shift towards using configuration management systems such as Puppet, Chef, SCCM, vCAC, PowerShell DSC and others that provide the ability to create runbooks that will be used to create and configure application and server environments.

If you’re using Puppet, you may already have tests built into your process to ensure that your configuration management scripts, manifests in this case, are syntacticly correct, and will work as expected. Puppet has great methods to do this luckily and is a great example of taking TDD onto the Ops side by extending a little further with Cucumber.

Chef is also able to be extended nicely into a TDD with Cucumber which is something that any operations admin should be making sure to move towards. We’ve been given some powerful capabilities between Puppet and Chef to manage our application dependencies and underlying operating system components, so adding TDD capabilities is a natural and positive step.

Time to Pester your PowerShell

If you’re using PowerShell as a scripting language to do configuration management, you now have options to introduce TDD methodologies for PowerShell, which has been a long sought after piece of the puzzle to ensure consistency. Now we are lucky to have a new product called Pester that is a unit testing framework for PowerShell.

Windows administrators are now able to take advantage of the PowerShell DSC (Desired State Configuration), which extends standalone PowerShell scripting into a more full featured configuration management product. This allows for powerful in-guest configuration that can be centrally deployed and managed. While SCCM did a lot to advance application deployment, lacks the lightweight ease of use that PowerShell DSC can offer.

Regardless of the tool that you choose, embracing TDD methodologies for your infrastructure configuration management tools is the next evolution for Ops teams to ensure predictable, testable, reliable infrastructure. This is the best way to start the journey towards DevOps and to help our Devs get the best out of our infrastructure.

So, when someone says to you “If it ain’t broke, don’t fix it”, you can simply and confidently reply with “if it ain’t broke, you haven’t built a test for it yet."

Image source: