Behaviour Driven Infrastructure

| No Comments | No TrackBacks
Lindsay Holmwood is talking about how to add behavioural driven development to infrastructure. He described test driven development. Starting with unit tests. Behaviour driven development is a reaction to thos tests, like can a user perform a particular task. So it's more system level tests. So it's more about testing the business needs, verifying functional requirements. The business doesn't care so much about how the solution is implemented.

So the business type of tests are outside-in tests. Possibly automated, possibly manual. There has been a movement to specifying theses tests in a language businesses can under stand (they can read it), but in a syntax the programmer can automate.

Andrew Schafer (a founder of puppet labs) suggests infrastructure is a application (this is an abstration). The daemons (such as database or web server) are your libraries, the configuration management is your code. And Cod without tests is bad. So we're bringing tools that developers have been using, and bringing them over to testing your infrastructure.

Cucumber is a tool to write tests (in high level language), and a tool to execute that specification. Lindsay popped up an example. It had a bunch of components, each of which was like a unit test. Then combining them all together was like a system test.

He showed an example of doing cucumber stuff, using his cucumber-nagios shortcuts/tool. Except he had some problems with using the rubygems bundle program, and stuff didn't work for him.

So once you've got these tests, you can do continuous integration. You can re-run the tests when you commit changes to your manifests. He speculates whether you want to run the tests on Production or Staging, or UAT. He asked how you do destructive tests. He asked how you apply the setup/teardown pattern from development testing to infrastructure. He suggested you have A/B testing (but didn't really say what it was). He doesn't have any answers for how you do that, without breaking production.

He moved onto the topic of how do you migrate to a configuration management environment from a system that was hand built. He suggested that you can write a bunch of tests to model the behaviour of the existing systems, and when they all pass, you run the same behavioural tests on a new configuration managed environment.

He suggests we've been running the wrong questions in our monitoring. The standard checks are ping checks, or connect checks. We normally do 'unit tests' of the infrastructure. He says cucumber lowers the barrier of entry to writing good system level checks. He's also saying that cucumber provides a common specification format that dev and ops can share, or/and that IT and business can share.

He talked about some movements within the cucumber community to put together a forge of common specifications.

No TrackBacks

TrackBack URL:

Leave a comment

About this Entry

This page contains a single entry by Geoff Crompton published on January 26, 2011 11:34 AM.

LCA2011 Wednesday morning keynote was the previous entry in this blog.

scaling programs is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.



Powered by Movable Type 4.23-en