Adding an Assertion
So, following Cucumber’s lead, we need to create a Ruby file for our program. Let’s just create an empty Ruby file for the time being so that we can stay on the outside and get the test finished before we go on to the solution. Linux/Mac users can type this to create an empty file:
| | $ touch calc.rb |
If you’re using Windows, there is no touch command, so either just create an empty text file named calc.rb in your editor or use this little trick:
| | C:> echo.>calc.rb |
When we run cucumber again, we should see that the second step is passing and we’re on to the final step:
| | $ cucumber --format progress |
| | ..P |
| | |
| | (::) pending steps (::) |
| | |
| | features/step_definitions/calculator_steps.rb:14:in ‘/^the output should |
| | be "([^"]*)"$/’ |
| | |
| | 1 scenario (1 pending) |
| | 3 steps (1 pending, 2 passed) |
| | 0m0.356s |
To get the last step definition working, change the last step definition in features/step_definitions/calculator_steps.rb to look like this:
| | Then(/^the output should be "([^"]*)"$/) do |expected_output| |
| | expect(@output).to eq expected_output |
| | end |
We’re using an RSpec assertion to check that the expected output specified in the feature matches the output from our program that we stored in @output in the previous step definition. If it doesn’t, RSpec will raise an error just like we did using raise in the last step definition. Now when we run cucumber, we have ourselves a genuine failing test:
We’ve implemented a step that calls the calculator program and passes, even though the “program” is just an empty file. What’s going on here?
Remember that a step isn’t a test in itself. The test is the whole scenario, and that isn’t going to pass until all of its steps do. By the time we’ve implemented all of the step definitions, there’s only going to be one way to make the whole scenario pass, and that’s to build a calculator that can perform additions!
When we work outside-in like this, we often use temporary stubs like the empty calculator program as placeholders for details we need to fill in later. We know that we can’t get away with leaving that as an empty file forever, because eventually Cucumber is going to tell us to come back and make it do something useful in order to get the whole scenario to pass.
This principle, deliberately doing the minimum useful work the tests will let us get away with, might seem lazy, but in fact it’s a discipline. It ensures that we make our tests thorough: if the test doesn’t drive us to write the right thing, then we need a better test.
| | $ cucumber --format progress |
| | ..F |
| | |
| | (::) failed steps (::) |
| | |
| | |
| | expected: "4" |
| | got: "" |
| | |
| | (compared using ==) |
| | (RSpec::Expectations::ExpectationNotMetError) |
| | ./features/step_definitions/calculator_steps.rb:16 |
| | features/adding.feature:6 |
| | |
| | Failing Scenarios: |
| | cucumber features/adding.feature:3 # Scenario: Add two numbers |
| | 1 scenario (1 failed) |
| | 3 steps (1 failed, 2 passed) |
| | 0m0.360s |
Great! Now our test is failing for exactly the right reason: it’s running our program, examining the output, and telling us just what the output should look like. This is a natural point to pause for a break. We’ve done the hard work for this release: when we come back to this code, Cucumber will be telling us exactly what we need to do to our program to make it work. If only all our requirements came ready-rolled with a failing test like this, building software would be easy!
Try This
Can you write an implementation of calc.rb that makes the scenario pass? Remember at this stage, we have only a single scenario to satisfy, so you might be able to get away with quite a simple solution.
We’ll show you our solution in the next section.