Without thinking too much about what they mean, let’s just copy and paste the snippets from Cucumber’s last output into a Ruby file. Just like the features, Cucumber is expecting the step definitions to be found in a conventional place:
| $ mkdir features/step_definitions |
Now create a Ruby file in features/step_definitions, called calculator_steps.rb. Cucumber won’t mind what you call it as long as it’s a Ruby file, but this is a good name to use. Open it in your text editor and paste in those snippets:
| Given(/^the input "([^"]*)"$/) do |arg1| |
| pending # express the regexp above with the code you wish you had |
| end |
| |
| When(/^the calculator is run$/) do |
| pending # express the regexp above with the code you wish you had |
| end |
| |
| Then(/^the output should be "([^"]*)"$/) do |arg1| |
| pending # express the regexp above with the code you wish you had |
| end |
Running cucumber will tell us what to do next:
| Feature: Adding |
| |
| Scenario: Add two numbers |
| Given the input "2+2" |
| TODO (Cucumber::Pending) |
| ./features/step_definitions/calculator_steps.rb:2 |
| features/adding.feature:4 |
| When the calculator is run |
| Then the output should be "4" |
| |
| 1 scenario (1 pending) |
| 3 steps (2 skipped, 1 pending) |
| 0m0.019s |
The scenario has graduated from undefined to pending. This is good news, because it means Cucumber is now running the first step, but as it did so, it hit the call to pending inside our copied-and-pasted step definition code, which tells Cucumber that this scenario is still a work in progress. We need to replace that pending marker with a real implementation.
Notice that Cucumber reports the two other steps as skipped. As soon as it encounters a failed or pending step, Cucumber will stop running the scenario and skip the remaining steps.
Let’s implement the first step definition.