Test-Driven Infrastructure with Chef

On With the Show

A great way to remind yourself where you are, when doing TDD, is to run your tests. When I’m working on some code, I like to leave myself a failing test, because the next day when I return to my desk, the first thing I do is run my tests. As soon as I see the broken test, my context starts to get reloaded and I know what I need to do next—make the test pass. Let’s run the test, and see how far it gets:

Then a user should be able to ssh to the server
  expected false to be true (RSpec::Expectations::ExpectationNotMetError)
  features/team_login.feature:10:in `Then a user should be able to ssh to the server'

Failing Scenarios:
cucumber features/team_login.feature:7 # Scenario: Users can connect to server via ssh key

Ah, yes—we need to write our Chef code to allow the users to connect via ssh. Let’s turn our mind back to the middle of our three step definitions:

When /^the technical users recipe is applied$/ do
  set_run_list('teamserver', 'recipe[users::techies]')
  run_chef('teamserver')
end

This step is now pretty clear—it takes the techies recipe from the users cookbook, adds it to the run list for the teamserver node, and then runs Chef. Remember this test already passed—it’s the next one we need to worry about:

Then /^a user should be able to ssh to the server$/ do private_key = Pathname(File.dirname(__FILE__)) + "../support/id_rsa-cucumber-chef" Given 'I have the following public keys:', table(%{ | keyfile | | #{private_key} | }) Then 'I can ssh to the following hosts with ...