Load data in cucumber/gherkin from external file

Viewed 683

I'm using cucumber (and writing tests in gherkin) in a JS/Node project, and I've found myself duplicating lots of test data (Scenario Outline examples) in different examples.

Most of the cases is using a list of users with different properties which need to be used to ensure that different parts of a webpage work for all of them.

Therefore tests end as something like this:

Scenario: s1
  Given xxx
  Then yyy <field1>
  Then zzz <field2>

Examples:
  | username | field1 | field2 |
  | user1    | f11    | f21    |
  | user2    | f12    | f22    |

Scenario: s2
  Given xxx
  Then yyy <field1>
  Then zzz <field2>

Examples:
  | username | field1 | field2 |
  | user1    | f11    | f21    |
  | user2    | f12    | f22    |

As you can see, examples for scenarios s1 and s2 are the same... so I thought it would be a good idea to load them from a external file, making it easy to share across scenarios/files (this is just a simple example with 2 scenario, but think about a real app with lot of features).

If the data for a user is updated it means I'd must update all of the examples... while if I just load it from an external file it would be only one place to update.

I've seen that some sites provide that feature, such as here, but couldn't figure how to do it on my own to have something like:

Scenario: s2
  Given xxx
  Then yyy <field1>
  Then zzz <field2>

Examples: {"dataFile":"./users.csv"}

There are always alternatives like, pre-processing .feature files and replace those lines with the content of the files or something like that... but I was wondering if there's something more native or direct, as I don't want to go to that path, or heavy-customization...

I couldn't find anything so anything would be welcome.

1 Answers

You cannot use the feature file to do any programming. This is by design as the feature file is intended to be a human readable form of documentation; it should describe the intended behaviour of the system in a way that both business and IT stakeholders can understand.

With that in mind, the question becomes whether you need to add the details of fields and their values in your feature file. Does having these details make the file easier to understand? (Spoiler: it does not).

My advice is to move these details down into the step definitions, and describe a particular case (step/scenario/example) only in high level terms.

For example, one of the systems I work on processes orders. We have different types of orders with different types of products, delivery methods, payments methods etc. While all of those fields need to be filled for each order, not all of them are relevant to any particular scenario. So we describe the relevant part in the feature file and use defaults for the rest of the data. This data is set in helper methods that create the objects we need, the step definition calls the relevant helper method(s) for a particular step / scenario.

So the step Given an order with credit card payment would create a default order and add a credit card payment. A step Given an order with multiple products creates an order with multiple products (and default payment information etc).

(And while you could store this data in Excel or other files and read it from there, I can tell you from experience that this will make your life harder, not easier. Setting this up will take more time than using your programming language to create objects / data, and also your tests will take longer to run because processing the files takes time).

Related