Aruba’s step definitions are a great example of how step definitions should be written. Each of them is hardly ever more than a single line long, delegating all its work to Ruby methods in Aruba’s support layer module Aruba::API. We can call these methods directly from our own step definitions, removing an unnecessary layer of indirection in our code. Here’s how the features/step_definitions/calculator_steps.rb file looks with each of the Aruba step definitions translated to their underlying method calls:
| Given /^the input "([^"]*)"$/ do |input| |
| write_file 'input.txt', input |
| end |
| When /^the calculator is run$/ do |
| run 'calculator input.txt' |
| end |
| When /^the calculator is run with no input$/ do |
| run 'calculator' |
| end |
| When /^I enter the calculation "([^"]*)"$/ do |calculation| |
| type calculation |
| end |
| Then /^the output should be "([^"]*)"$/ do |output| |
| expect(last_command_stopped).to have_output an_output_string_including(output) |
| end |
Run cucumber, and you should see the feature is still passing just as before. We find this preferable to leaving the calls to steps in our step definitions. Once we’re down into the step definitions layer, we like to keep things simple and work in pure Ruby rather than mixing Gherkin and Ruby together.