-
Notifications
You must be signed in to change notification settings - Fork 0
Home
I finally looked into cucumber last week and immediately loved it. Within a couple hours I had several features written for an existing application. By the end of the next day, our whole team was writing cucumber features, and enjoying it! Cucumber seems to have brought back an excitement to testing that I haven’t felt for a while (since my first few weeks with RSpec).
Cucumber is a tool that can execute feature documentation written in plain text.
Cucumber targets non technical business analysts, interaction designers, domain experts, testers (for the plain text part)
and programmers (for the steps, which are written in Ruby).
Cucumber itself is also written in Ruby, but it can be used to “test” code written in Ruby, Java (or web applications written
in any language). When IronRuby matures it can be used to “test” .NET code too.
Cucumber only requires minimal use of Ruby programming, so don’t be afraid to try it out even if the code you’re
developing is in a different language. Most programmers should pick up the required Ruby skills and be productive
with Cucumber in a few of days.
While Cucumber can be thought of as a “testing” tool, the intent of the tool is to support BDD.
This means that the “tests” (plain text feature descriptions with scenarios) are typically written before anything else, and
the production code is then written outside-in, to make them pass.
(Rails people – see Ruby on Rails).
After you have installed Ruby or JRuby – install Cucumber with the following command:
Ruby:
gem install cucumberJRuby:
jruby -S gem install cucumberGet the code via Git (or download a tarball).
git clone git://github.com/aslakhellesoy/cucumber.git
cd cucumber
rake gem # If you're on Windows this might fail because of missing tar.exe. Try installing MSYS.
rake install_gem
There are several ways to get started, depending on the architecture of your application.
Take a look at the examples.
Each example directory has a Rakefile, and you can run the features in an example directory with
rake featuresThe examples deliberately have errors so you can get a taste of how the error output looks like. You can get help by asking
for it:
cucumber --helpOnce you have set up Cucumber in your project you can get down to action.
When you decide you want to add a new feature or fix a bug, start by writing a new feature or scenario that describes
how the feature should work. Don’t write any code (yet).
Now run the features again. The one you wrote should have yellow, pending steps – or failing, red ones.
(If you don’t get that you’re doing something wrong, or the feature is already implemented).
This is when you start writing code. Start by writing a couple of lines of code to address the failure you got from Cucumber.
Run cucumber again. Repeat and rinse until you’re happy with your feature. When you get down to nitty gritty details, drop
down one abstraction level and use RSpec to write some specs for your classes. Write the specs first! If you follow this
process you have a good guard against brittle, unmaintainable, undocumented code that nobody understands.
(Yes, stories and specs are documentation too).
If you think this sounds annoying, try it out anyway. You’ll end up writing better, lesser coupled (and less) code this way. Trust me.
Work outside-in (the outside being the feature, the inside being the low level code). Do it the BDD way.
You should discuss the “In order to” part of the feature and pop the “why” stack max 5 times (ask why recursively)
until you end up with one of the following business values:
- Protect revenue
- Increase revenue
- Manage cost
If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to
implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on
implementing the MMFs (Minimal Marketable Features) that will yield the most value.
The value provided by a system is what you can get out of it – not what you put into it. Just like the value
is expressed at the top of a feature (In order to…), the value should be in the steps of a scenarios too,
more precicely in the Then steps.
When you’re writing a new scenario, I recommend you start with the formulation of the desired outcome. Write the
Then steps first. Then write the When step to discover the action/operation and finally write the Given
steps that need to be in place in order for the When/Then to make sense.