For more information: http://extremia.fi/ (in Finnish) or http://extremia.net/ (in English)

1. BDD and Cucumber (Part II)
http://extremia.fi/ • http://extremia.net/

2. BDD and Cucumber
• As time progresses and you create more
cucumber features running all of them at once
becomes impractical.
• Some of the features deal with more static
pieces of the system that don’t really change
over time and could be ran only once a day
(nightly builds).
• Cucumber offers a few solutions for mitigating
this problem.
http://extremia.fi/ • http://extremia.net/

3. Using tags to filter test cases
• An easy and fast way to reduce test runs for
features that deal with pieces that are not
actively being developed mark them with a
common tag (such as @nightly) and running
the cucumber features with, for example:
cucumber --tags ~@nightly
• You could just as well tag all your scenarios
with some relevant tags and use
cucumber --tags @TAG_1,@TAG_2…
http://extremia.fi/ • http://extremia.net/

4. Using tags to filter test cases
• The downside with this kind of tagging is a bit of
a maintenance overhead, as the logical groupings
of what you’re working on will inevitably change
requiring the tags to change with them.
• In a larger project with multiple developers or
even teams the tags can also mix up making your
scenarios more brittle and likely to run scenarios
you didn’t intend resulting again in unnecessary
testing overhead and a longer feedback loop.
http://extremia.fi/ • http://extremia.net/

5. Filtering based on scenario name or
line
• Cucumber scenarios can also be filtered based on
a single or multiple lines using line numbers by
running
cucumber features/some.feature --line 13 or
cucumber features/some.feature:13
• You could even filter by the scenario name but be
careful as cucumber will match every scenario
with the given text. So, for example, every
scenario with email in its name would be run on
cucumber --name email
http://extremia.fi/ • http://extremia.net/

6. Splitting between RSpec and
Cucumber
• In addition to filtering test cases using
Cucumber, a significant gain in test run time can
be gained by running more fine grained tests
using RSpec.
• For example, to make sure a user is notified when
some event has occurred in the system with
relevant information you might be inclined to test
each of the possible messages using cucumber.
http://extremia.fi/ • http://extremia.net/

7. Splitting between RSpec and
Cucumber
• Assuming that each of the messages is shown to
the user using the same programming logic our
integration tests (cucumber) could simply check
for one of these messages, leaving the quicker
unit tests to worry about the rest of the
notifications.
• Doing so could result in significant gains in test-
to-feedback-loop thus making sure the tests are
actually run more often.
http://extremia.fi/ • http://extremia.net/