Cover by Stephen Nelson-Smith

Safari, the world’s most comprehensive technology and business learning platform.

Find the exact information you need to solve a problem on the fly, or go deeper to master the technologies and skills you need to succeed

Start Free Trial

No credit card required

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

Find the exact information you need to solve a problem on the fly, or go deeper to master the technologies and skills you need to succeed

Start Free Trial

No credit card required