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

Get Test-Driven Infrastructure with Chef now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.