You are previewing Test-Driven Infrastructure with Chef.

Test-Driven Infrastructure with Chef

Cover of Test-Driven Infrastructure with Chef by Stephen Nelson-Smith Published by O'Reilly Media, Inc.
O'Reilly logo

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]')

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 ...

The best content for your career. Discover unlimited learning on demand for around $1/day.