Gem Version Build Status Code Climate Dependency Status RubyDoc Documentation

Gurke is an experimental, alternative cucumber runner. It ~~steals~~ borrows ideas and concepts from turnip, rspec and tries to avoid cucumber.

That includes * Step definitions in modules * Before, After and Around hooks * Formatters * Partial step inclusion (via modules) * Keyword-dependent steps * Scenario-local world * Running DRb background test server.


Or install it yourself as:

$ gem install gurke

Or add it to your Gemfile and install it using bundler.

Note: Install version 2.0+. Previous versions were something else.


  1. Put features in features/.

  2. Put support and configuration files as ruby into features/support/**.


# features/support/gurke.rb
require 'gurke/rspec'
require 'tmpdir'

Gurke.configure do |c|
  c.around(:scenario) do |scenario|
    Dir.mktmpdir('gurke') do |dir|
      @__root =
  1. Put your step definitions into features/support/**.
# features/support/steps/file_steps.rb
module FileSteps
  step(/a file "(.*?)" with the following content exists/) do |path, step|
    file = @__root.join(path)

    File.write(file, step.doc_string)

Gurke.configure{|c| c.include FileSteps }

You can also use an existing method as a step:

module MySteps
  def do_something(arg)
    # ...

  step(/I do something: "(.*?)"/, :do_something)

  # Easy call it from another step
  step(/I do something else/) { do_something('abc') }

You can include some steps to only scenarios with specific tags:

module MyStepsA
  step(/I do something/) { ... }

Gurke.configure{|c| c.include FileSteps, tags: 'tagA' }

module MyStepsB
  step(/I do something/) { ... }

Gurke.configure do |c|
  c.include FileSteps, tags: [:tagB, 'bType'] # At least one tag has to match

Therefore you can use different step implementations for same named steps depending on the tags of the the feature and scenario.

Keyword specific step definitions

You can also define steps for only a specific keyword. This also allows you to use the same step pattern for different keywords, e.g.

module PathSteps
  Given(/^I am on the start page$/) { visit '/' }
  Then(/^I am on the start page$/) { assert current_path == '/' }

Therefore you can write your scenarios in a documentary style of facts:

Scenario: Use the back button
  Given I am on the start page
  When I click on "Go to another page"
  And I click the back button
  Then I am on the start page

And and But steps will inherit the keyword type from the step before, e.g. the And step above will be of the when type.

Included Step Definitions & Hooks

Each scenario runs in it's own world. All modules registered to be included will be included in this world. Before and after scenario or step hooks will also be executed within this world. All steps are run in this world.

You can define hooks similar to RSpec:

Gurke.configure do |config|
  config.before(:scenario) do
    visit '/' # Example: Start each scenario on index page

  config.after(:features) do
    # Do some cleanup code etc.

The following hooks are available:

  • :features: Will be run before and after every feature. Use to to initially setup or teardown needed resources e.g. setup capybara.
  • :feature: Will be run before and after any feature.
  • :scenario: Same for any scenario.
  • :step: Can be used to e.g. screenshot browser for every step.

Use the command line runner

Run all scenarios by just calling bundle exec gurke. By default scenarios and features tagged with @wip will be ignored.

Specify one or more --tags or -t arguments to filter for specific tags, negate tag filters with ~.


  • --tags a,b - only run scenarios with tags @a AND @b
  • -t a -t b - only run scenarios with tags @a OR @b
  • -t a,~b - only run scenarios with @a but not @b

You can also specify a list of files that will be run:

gurke features/my_feature.feature

If you append one or more line numbers - separated by colons - only the scenarios defined around the given lines will be run:

gurke features/my_feature.feature:14:34

DRb background server (experimental)

You can run a DRb server in the background that has a running test environment (whatever that means to you) by running gurke --drb-server. This will load your test environment and execute all before :system hooks.

You can later run your features (or specific features) by running gurke --drb. That will run the features in the already loaded DRb server, including all other hooks.

Remember to reload e.g. your step definitions before :features to pick up changes:

  config.before(:features) do
    Dir['features/steps/**/*.rb'].each{|f| load f }

Use the after :system hook to shutdown resources.

Remember to restart background server when changing hooks, configuration or removing/redefining steps as otherwise the changes won't be picked up or steps won't change or are ambiguous now.


  • Add context/ctx object to world providing current feature/scenario/step
  • Define scenario specific after hook in a step (e.g. to close opened resource)
  • Random run order (rspec)
  • Using strings with placeholders as step pattern (turnip)
  • Custom placeholders (turnip)
  • More reporters (NyanCat / JUnit / TeamCity / Adapter to run multiple reporters)
  • SimpleCov support (and use it in own tests)
  • Scope hooks by scenario tags
  • Fast-fail
  • Additional feature-scope and global worlds


Now: * Can finally (start to) test itself.


Send me code.