What We Just Learned
It’s useful to think of a step definition as being a special kind of method. Unlike a regular Ruby method, whose name has to match exactly, a step definition can be invoked by any step that matches its regular expression. Because regular expressions can contain wildcards, this means you have the flexibility to make the Gherkin steps nice and readable, while keeping your Ruby step definition code clean and free of duplication.
-
Step definitions provide a mapping from the Gherkin scenarios’ plain-language descriptions of user actions into Ruby code, which simulates those actions.
-
Step definitions are registered with Cucumber by calling Given, When, Then, or one of the aliases for your spoken language.
-
Step definitions use regular expressions to declare the steps that they can handle. Because regular expressions can contain wildcards, one step definition can handle several different steps.
-
A step definition communicates its result to Cucumber by raising, or not raising, an exception.
Now that you’ve seen how Gherkin and step definitions fit together, you’re ready to start using Cucumber to test your own applications. To get your step definitions talking to the application, you’ll need to learn how to use one of Ruby’s automation libraries, many of which are covered in the recipes part of this book. If you’re testing a web application, for example, see Chapter 15, Using Capybara to Test Ajax Web Applications, and if your web application runs on Ruby on Rails, see Chapter 14, Bootstrapping Rails. If you want to test a command-line application, try Chapter 16, Testing Command-Line
Applications with Aruba. Web services are covered in Chapter 12, Testing a REST Web Service.
Over here in the fundamentals part, we’re going to start putting some more flesh on the bones of your Cucumber knowledge. There’s much more to Gherkin than the basic keywords we taught you in the previous chapter, and that’s what we’ll explore next.
Try This
At the end of the previous chapter, we suggested that you write some scenarios for your own project. Now try running them with Cucumber and use the snippets to create your first step definitions. Think about which domain entity each step is working with, and use that to decide which file to put the step definition into. Look for places you can use what you’ve learned about regular expressions to make the step definitions more flexible.
When making assertions in Cucumber step definitions, there are a few different libraries you could choose. The main candidates are RSpec,[10] MiniTest,[11] and Wrong.[12] We’ll give you a quick overview of each one’s strengths, and you can choose your favorite. Here’s a quick example of each of them in use:
| | # MiniTest |
| | >> require 'test/unit' |
| | >> include Test::Unit::Assertions |
| | >> assert_equal 'green', 'cucumber' |
| | MiniTest::Assertion: <"green"> expected but was |
| | <"cucumber">. |
| | |
| | # RSpec |
| | >> require 'rspec/expectations' |
| | >> "green".should == "cucumber" |
| | RSpec::Expectations::ExpectationNotMetError: expected: "cucumber" |
| | got: "green" (using ==) |
| | |
| | # Wrong |
| | >> require 'wrong' |
| | >> include Wrong |
| | >> assert { 'green' == 'cucumber' } |
| | Wrong::Assert::AssertionFailedError: Expected ("green" == "cucumber"), but |
| | Strings differ at position 0: |
| | first: "green" |
| | second: "cucumber" |
MiniTest’s assertions are built into Ruby, which makes them a handy tool to reach for. They use a style of assertion that you’ll be familiar with if you’re used to making assertions in any xUnit testing framework.
RSpec’s assertions are automatically loaded by Cucumber. Their style emphasizes readability.
Wrong is a new kid on the block. It uses Ruby magic tricks to read the code you’ve passed to the assertion to produce really helpful error messages.
In the end, the choice is a personal preference as to which syntax you prefer; all of the libraries provide roughly the same set of functionality.