5
votes

I am new to Cucumber testing.

I have created two features files:

events.feature
partner.feature

and have my step definitions in a step_definitions folder:

./step_definitions/
     events.rb
     partner.rb

It seems that Cucumber looks in all the .rb files for the step information.

Is there anyway of restricting the feature to look at a specific step definition file?

The reason as to why I want to do this, is because I am getting Ambiguous match errors, even when I use the --guess flag.

The reason as to why I want to do this is for the following reasons. I am testing a CMS, and want to test each of the different content types (events & partners) in separate features.

events.feature

Feature: Add partner
  As an administrator I can add a new partner

  Scenario: Create partner
    Given I am logged in
    When I create a partner
    Then I should see content

partner.feature

Feature: Add event
  As an administrator I can add a new event

  Scenario: Create event
    Given I am logged in
    When I create an event
    Then I should see content

Just focusing on the 'then I should see content' which is in both scenarios, the error occurs because in the .rb files I need to include:

partners.rb

Then /^I should see content$/ do
  BROWSER.html.should include('SOME PARTNER CONTENT')
end

events.rb

Then /^I should see content$/ do
  BROWSER.html.should include('SOME EVENT CONTENT')
end

which means there is an Ambiguous match of "I should see content".

I understand there are different ways of structuring this, i.e. I could create a content feature, and use scenario outlines:

Feature: Add content
  As an administrator I can add a new content

  Scenario Outline: Create content
    Given I am logged in
    When I create an <content type>
    Then I should see <example content>

    Examples: 
    |event   |March Event | 
    |partner |Joe Blogs   | 

But I don't want to do this because I want to encapsulate each content type in their own test feature.

So essentially I need to work out how to run specific step files according to the feature I am testing.

3

3 Answers

9
votes

Cucumber always loads all files and I don't think that there is a way to override this behavior. Regarding your problem with ambiguous steps - the solution is easy - add parameters to your steps

Then /^(?:|I )should see "([^"]*)"$/ do |text|
  page.should have_content(text)
end

And in scenarios just call it like this

Then I should see "PARTNER CONTENT"

  • free bonus - your scenario is now much more readable
1
votes

I don't see anything wrong with the alternative approach that you suggested. Separating out the step definitions into logical domains makes sense. However, it seems like you may be trying to take it too far, and that's going to lead to a good deal of duplicated code and issues with ambiguous matches like you're seeing now. I'd recommend doing something like this:

Feature: Add partner
  As an administrator I can add a new partner

  Scenario: Create partner
    Given I am logged in
    When I create a partner
    Then I should see "partner content"

And, similarly, in your event feature:

...
Then I should see "event content"

Then you could the following in a separate step_definitions/common_steps.rb file:

Then /I should see "(.*)"$/ do |content|
   BROWSER.html.should include(content)
end

This step doesn't have anything partner/event specific about it. Instead, the scenarios contain the data-specific strings for your features.

If you are working on a Rails app, the cucumber-rails gem will actually create a bunch of common steps for web application testing for you. Even if you aren't using Rails, it might be useful to take a look at some of these steps.

0
votes

I've been looking for this, but it appears not to be possible "out of the box".

My solution is to differentiate steps always using some kind of additional description, such as class name, for example:

Scenario: Buildings List
    Given I have a Building with code "B1"
    And I have a Building with code "B2"
    When I go to the list of buildings
    Then I should see "B1" building code
    And I should see "B2" building code

These "building code" descriptions are all you need not to reuse steps between different files / domains.