Running Our Program
To implement the next step, edit features/step_definitions/calculator_steps.rb so that the second step definition looks like this:
| | When(/^the calculator is run$/) do |
| | @output = `ruby calc.rb #{@input}` |
| | raise('Command failed!') unless $?.success? |
| | end |
This code attempts to run our calculator program calc.rb, passing it the input we stored in the first step and storing any output in another instance variable. Then it checks a specially—but rather cryptically—named Ruby variable $? to check whether the command succeeded and raises an error if it didn’t. Remember that Cucumber fails a step if the step definition raises an error; this is the simplest way to do it.
This time when we run Cucumber, we should see that it has actually tried to run our calculator:
| | Feature: Adding |
| | |
| | Scenario: Add two numbers |
| | Given the input "2+2" |
| | ruby: No such file or directory -- calc.rb (LoadError) |
| | When the calculator is run |
| | Command failed! (RuntimeError) |
| | ./features/step_definitions/calculator_steps.rb:10 |
| | features/adding.feature:5 |
| | Then the output should be "4" |
| | |
| | Failing Scenarios: |
| | cucumber features/adding.feature:3 |
| | |
| | 1 scenario (1 failed) |
| | 3 steps (1 failed, 1 skipped, 1 passed) |
| | 0m0.088s |
Our step is failing, because we don’t have a calc.rb program to run yet. You should see that Cucumber has highlighted the output from our raised error in red just beneath the step, helping you spot the problem.
You might well think it’s a bit odd that we’ve written and run code that tries to run our calc.rb program, knowing perfectly well that the file doesn’t even exist yet. We do this deliberately, because we want to make sure we have a fully functioning test in place before we drop down to working on the solution. Having the discipline to do this means we can trust our tests, because we’ve seen them fail, and this gives us confidence that when the tests pass, we’re really done. This gentle rhythm is a big part of what we call outside-in development, and while it might seem strange at first, we hope to show you throughout the book that it has some great benefits.
Another benefit of working from the outside-in is that we’ve had a chance to think about the command-line interface to our calculator from the point of view of a user, without having made any effort to implement it yet. At this stage, if we realize there’s something we don’t like about the interface, it’s very easy for us to change it.