Nikolay Sturm's Blog

Musings about Development and Operations

Writing Cucumber Features for Configuration Management

| Comments

I am test-infected, so when I played around with Vagrant and Chef the other day, I was wondering how a test-driven approach to writing cookbooks might look like.

I started with plain Cucumber and wrote a scenario like this one:

1
2
3
4
Scenario: Uninstall ntpd on VM
  Given recipe "ntp"
  When I provision a new virtual machine
  Then package "ntp" should be purged

Having played with Cucumber and Puppet for a long time, I realised, that I was entering the old road of 1-to-1 map between test and implementation. My Chef recipe looked liked this:

1
2
3
package "ntp" do
  action :purge
end

In this situation I remembered a blog post from Antony Marcano where he argues for a Goal -> Task -> Action approach to writing scenarios. This way it should be simpler to find an adequate level of abstraction by hiding concrete actions in step implementations.

In my case purging the package is even below the action level. I want to specify that the ntp daemon should not be running and leave it to the implementation, i.e. the chef recipe, how to get there. This is an improved scenario:

1
2
3
4
Scenario: don't run ntpd on a virtual machine
  Given recipe "ntp"
  When I provision a new virtual machine
  Then "ntpd" should not be running

This is much better, as it decouples the Cucumber feature from the configuration management details. If I ever need the ntp package installed for whatever reason, but ensure the service being disabled, the scenario won’t break as it would have in the first case. I could probably even switch from Chef to Puppet with minimal efforts.

Comments