Cucumber is a framework for writing and executing high level descriptions of your software's functionality. Call these tests, examples, specifications, whatever... it doesn't matter too much. What I'm talking about has traditionally been called functional, integration, and/or system tests. In XP terms this includes tests called Story Tests, Customer Tests, and/or Acceptance Tests.
One of Cucumber's most compelling features is that it provides the ability to write these descriptions using plain text in your native language. Cucumber's language, Gherkin, is usable in a growing variety of human languages, including LOLZ. The advantage of this is that these feature descriptions can be written and/or understood by non-technical people involved in the project.
One important thing to keep in mind is that Cucumber is NOT a replacement for RSpec, test/unit, etc. It is not a low level testing/specification framework.
Cucumber plays a central role in a development approach called Behaviour Driven Development (BDD).
A Bit About BDD
Dan North describes BDD as “writing software that matters” in The RSpec Book and outlines 3 principles:
- Enough is enough: do as much planning, analysis, and design as you need, but no more.
- Deliver stakeholder value: everything you do should deliver value or increase your ability to do so.
- It's a behavior: everyone involved should have the same way of talking about the system and what it does.
BDD in its grandest sense is about communication and viewing your software as a system with behaviour. BDD tools such as RSpec and Cucumber strive to enable you to describe the behavior of your software in a very understandable way: understandable to everyone involved.
A feature is something that your software does (or should do), and generally corresponds to a user story and a way to tell when it's finished and that it works.
The general format of a feature is:
Within the definition of a feature you can provide a plain text description of the story. You can use any format for this, but having some sort of template makes it easier to see the important bits of information with a quick glance. Once of the more common template is discussed by Mike Cohn in User Stories Applied:
This format focuses us on three important questions:
- Who's using the system?
- What are they doing?
- Why do they care?
Here's a sample story:
That defines who the user is (a code-breaker), what they want to do (start a game) and why (be able to break the code).
A feature is defined by one or more scenarios. A scenario is a sequence of steps through the feature that exercises one path. Cucumber uses the BDD style that Dan North put forth with his jBehave project: given-when-then.
A scenario is made up of 3 sections related to the 3 types of steps:
- Given: This sets up preconditions, or context, for the scenario. It works much like the
setupin xUnit and
beforeblocks in RSpec.
- When: This is what the feature is talking about, the action, the behaviour that we're focused on.
- Then: This checks postconditions… it verifies that the right thing happen in the When stage.
The general form of a scenario is:
Following our example, here's a scenario:
One thing to note is the last line. Notice the And. And can be used in any of the three sections. It serves as a nice shorthand for repeating the Given, When, or Then. And stands in for whatever the most recent explicitly named step was: Given, When, or Then. The last two lines above could have been:
That doesn't read nearly as well, though. Similarly, if you want to state a negative Then step, you can use But in place of Then, for example:
While there are no constraints on the number or order of steps, it is generally best to keep scenarios as simple as possible and have multiple simple scenarios. The closer your scenarios conform to the given-when-then format, the better.
So here's our feature:
If you run that you'll see an echo of the feature followed by (using Cucumber 0.3.11):
The next step (pardon the pun) is to define what each of our steps mean. When we executed our feature with no steps defined, Cucumber gave us skeletons for the undefined steps (see above). If we put those in the file features/step_definitions/codebreaker.rb and run it again, we get:
As you can see from above, the basic structure of a step definition is the keyword (i.e. Given, When, or Then) followed by a regular expression and a block of Ruby code. The regular expression is used to identify the desired step implementation. The step text in scenarios is matched against the regular expressions of appropriate (i.e. given, when, or then) step implementations to find the one to use. When a match is found, the substrings matching any groups in the regular expression are used as arguments to the block which is then evaluated. The result of that evaluation is discarded. Note that these arguments are always strings. If you need them converted to other types, it's up to you to do that conversion in the block. These groups and parameters have knowledge of position (i.e.. group 1 is used as the first parameter, group 2 as the second, and so on).
Notice that the suggested steps are completely concrete. While that is fine some of the time, you will generally want to refactor steps and make them more generic and reusable. Notice that there are two then step definitions that are much the same:
The difference is the string inside quotes (using quotes or similar delimiters is very handy for matching the groups). We can factor that out into a regex group:
Our given step could be:
Next is the when step:
This might be implemented as:
Now we have the variable
@messages that can be used in subsequent steps.
Recall how we left our then step definition:
We can now fill this in:
You can use whatever method of verification you want in the then steps: rspec, test/unit, shoulda, etc. I happen to prefer RSpec.
Earlier I mentioned that Cucumber supports various languages including LOLZ. Here's a feature in LOLZ:
And the step implementations:
And that's all there is to understanding the basics of Cucumber.