I started with plain Cucumber and wrote a scenario like this one:
1 2 3 4
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
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
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.