Domanda

I am writing a Rails testing suite using Cucumber.

I currently have a scenario which is very much like this.

Scenario Outline:
  Given I am logged in as "<user>"
  When I create a <fruit>
  Then I should see the <fruit> info
  When I click the <fruit> delete button
  Then I should see the confirmation "Fruit deleted"

  Examples:
    | user   | fruit  |
    | super  | apple  |
    | super  | banana |
    | ninja  | apple  |
    | ninja  | banana |
    | juicer | apple  |
    | juicer | orange |
    | cake   | apple  |
    | cake   | banana |
    | cake   | orange |

This works fine, but it doesn't seem very DRY. I would prefer something like this.

Scenario Outline:
  Given I am logged in as "<user>"
  When I create a <fruit>
  Then I should see the <fruit> info
  When I click the <fruit> delete button
  Then I should see the confirmation "Fruit deleted"

  Examples:
    | user   | fruits                |
    | super  | apple, banana         |
    | ninja  | apple, banana         |
    | juicer | apple, orange         |
    | cake   | apple, banana, orange |

Is this sort of thing possible? Am I even headed in the right direction with my test?

È stato utile?

Soluzione

It is technically possible to change your examples to group the fruits in a single scenario. Each of the steps would have to:

  1. Take the string of fruits
  2. Split them on the comma (assuming no fruits have a comma in them)
  3. Perform the action for each fruit

For example, your "Then I should see info" would look like:

Then /I should see the (.*) info/ do |fruit_array|
    fruits = fruit_array.split(',').map(&:strip)

    fruits_on_page = ['apple', 'banana', 'grape']

    fruits.all? do |fruit|
        fruits_on_page.should include fruit
    end
end

In terms of whether it is a good idea or not, I believe the recommendation would be to use your first approach with each individual fruit being an example. The reason being that having just one assertion per test (scenario) is easier to understand and debug. However, there could be reasons to combine the tests. For example, if each example takes an hour to run, perhaps you would save time by combining them. If there is an interaction with fruits, then it might make sense to combine them to test that interaction. Another reason for not changing it, is that while your scenarios might look dryer, you step definitions are now more complicated. As well, making multiple assertions in a step can be bad since only the first failed assertion is reported (though there are hacks to address this).

Altri suggerimenti

Two annotations:

  • If you just need to test if one (or two) user(s) can do CRUD actions on your app, perhaps you just split the use cases:

    • CREATE

      • userA can create a fruit named "banana"
      • userB can create a fruit named "banana"
    • DELETE

      • userA can delete a fruit named "banana"
      • userB can delete a fruit named "banana"
    • $ANOTHER ACTION

      • ...
  • There's a syntax error in your second feature: in the Examples section, the second column is "fruit", not "fruits"

Of course, you can use Cucumber's scenario outlines in a different DRYer way :-)

https://github.com/cucumber/cucumber/wiki/Scenario-Outlines

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top