To prevent step name conflicts, you can scope steps to specific tags. Turnip converts Gherkin tags (e.g., @interface) into RSpec metadata. You can then use RSpec's conditional include to only load certain modules when a specific tag is present.

module InterfaceSteps
  step "I do it" do
    ...
  end
end

module DatabaseSteps
  step "I do it" do
    ...
  end
end

RSpec.configure do |config|
  config.include InterfaceSteps, :interface => true
  config.include DatabaseSteps, :database => true
end

@interface
Scenario: do it through the interface

@database
Scenario: do it through the database

Alternatively, use the steps_for shortcut:

steps_for :interface do
  step "I do it" do
    ...
  end
end

Turnip supports substitution in Scenario Outline blocks for both DocStrings and Table arguments, similar to Cucumber. You can use <placeholder> syntax within the steps and DocStrings, which will be replaced by the values provided in the Examples table.

Scenario Outline: Email confirmation
  Given I have a user account with my name "Jojo Binks"
  When an Admin grants me <Role> rights
  Then I should receive an email with the body:
    """
    Dear Jojo Binks,
    You have been granted <Role> rights.  You are <details>. Please be responsible.
    -The Admins
    """
  Examples:
    |  Role     | details                                         |
    |  Manager  | now able to manage your employee accounts       |
    |  Admin    | able to manage any user account on the system   |

Turnip is a Gherkin extension for RSpec. It allows you to write Cucumber-style .feature files that run within your existing RSpec environment. Feature files are treated as specs and can be run using the standard rspec command or via rake spec.

# spec/acceptance/attack_monster.feature
Feature: Attacking a monster
  Background:
    Given there is a monster

  Scenario: attack the monster
    When I attack it
    Then it should die

rspec spec/acceptance/attack_monster.feature

To use Turnip with Capybara, require turnip/capybara in your spec_helper.rb. This allows you to use Cucumber-style tags (e.g., @javascript or @selenium) to switch between Capybara drivers. Turnip features are automatically run with the :type => :feature metadata, ensuring Capybara and any other added extensions are included in the execution context.

require 'turnip/capybara'

You can install Turnip as a gem or add it to your Gemfile. After installation, you must require the Turnip RSpec integration in your .rspec file to enable Gherkin support in your RSpec environment.

# Add to Gemfile
group :test do
  gem "turnip"
end

Add to .rspec

-r turnip/rspec

To make step definitions available across all your tests, define them within the Turnip::Steps module. Any methods added to this module will be treated as global steps.

module Turnip
  module Steps
    def i_login_as_admin
      # step implementation
    end
  end
end

In Turnip, a Feature represents a Gherkin feature definition. It acts as a container for other Gherkin elements such as Background, Scenario, ScenarioOutline, and Rule. When Turnip parses a feature file, it generates a Feature object containing metadata about the feature's name, description, language, and tags, along with its child elements.

# The Feature object contains metadata structured like this:
{
  type: :Feature,
  tags: [], # Array of Tag
  location: { line: 10, column: 3 },
  language: 'en',
  keyword: 'Feature',
  name: 'Feature name',
  description: 'Feature description',
  children: [], # Array of Background, Scenario and Scenario Outline
}

By default, Turnip marks a scenario as pending if a step is not implemented. If you want unimplemented steps to cause a failure instead, set raise_error_for_unimplemented_steps to true in your configuration.

# In spec/turnip_helper.rb or spec_helper.rb
RSpec.configure do |config|
  config.raise_error_for_unimplemented_steps = true
end

Turnip integrates with RSpec by hooking into the load method. When RSpec encounters a file ending in .feature, it automatically uses Turnip to run the Gherkin scenarios instead of treating it as a standard Ruby spec file.

To ensure proper integration, Turnip configures the RSpec pattern to include **/*.feature files and adds a configuration setting raise_error_for_unimplemented_steps (which defaults to false).

# The integration is typically applied automatically when Turnip is required,
# but it configures RSpec with the following settings:

::RSpec.configure do |config|
  config.include Turnip::Execute, turnip: true
  config.include Turnip::Steps, turnip: true
  config.pattern += ',**/*.feature'
  config.add_setting :raise_error_for_unimplemented_steps, :default => false
end

Turnip sends notifications to the RSpec reporter regarding step progress. You can create a custom RSpec formatter and register it to listen for specific step events. Supported notifications include :step_started, :step_passed, :step_failed, and :step_pending.

class MyFormatter
  RSpec::Core::Formatters.register self, :step_started, :step_passed, :step_failed, :step_pending
  
  def step_passed(step)
    puts "Starting step: #{step.text}"
  end

  # 
end

Since Turnip runs on RSpec, you can use standard RSpec hooks. To apply a hook to all Turnip features, specify the type as :feature.

# Global feature hooks
config.before(:type => :feature) do
  do_something
end

# Tag-specific feature hooks
config.before(:some_tag => true) do
  do_something
end

Steps are defined using the step method within a Ruby module. To make these steps available to your features, you must include the module in your RSpec configuration.

module MonsterSteps
  step "there is a monster" do
    @monster = Monster.new
  end
end

RSpec.configure { |c| c.include MonsterSteps }