How much data should be given in a cucumber feature file? - cucumber

Question

I'm trying to write some Gherkin feature files in order to do BDD acceptance testing using SpecFlow. The system I'm trying to test consists of multiple RESTful APIs - system has a microservice architecture. In a scenario, I need to be certain that some records already exist in the database prior to going with the actual scenario, so I've included a Background section with a given part. The problem I'm having is that each of those records that need to exist are created through APIs that require lots of data in their schema contact and the team requires that I specify each and every fields and their respective values in a record in a gherkin table. The result is something like this:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|
This is the header of one of my tables which is going to be used to create a Traveler record in the database before starting the actual test by specification. However, as you can see this table has too much fields and therefore is too long too fit on the screen and thus very hard to read and maintain. secondly it's tightly coupled to the DTO schema. I argued that we shouldn't put this much detail on our specificatons, trying to include only vital high-level data (e.g. given we have an existing traveler named "James Peterson") but the team and the CTO insisted that these details should be present on the feature file. In my next attempt, I broke the tables into multiple tables (e.g. personal data, order data, passport data, etc.).
But I'm still confused and I think I'm still not doing the wrie thing. What's your recommendation? Do we have any rule of thumb or best practices for this?

Answer 1

Can you transpose the filed and values in the data table as below.
|field |values |
| PassportExpireDate |[] |
| PassportNumber |[] |
| PassportCountry |[] |
| Firstname |[] |
| Lastname |[] |
| LocalFirstname |[] |
| LocalLastname |[] |
| Birthday |[] |
| NationalNumber |[] |
| NationalityCountryId |[] |
| PassengerType |[] |
| Gender |[] |
| PartyId |[] |
| SourceTravelerId |[] |
| CellNumber |[] |
| Price |[] |
And in the step def implement the logic to get the values from the values array.

Answer 2

Specflow supports external data binding for such cases. You can use Excel binding to keep your feature file fit.
Scenario Outline: Add Traveler
Given ...
When ....
Then ....
#source:TravelerRecordsExamples.xlsx
Examples:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|

Answer 3

TLDR None
Don't put definitions and data in a Gherkin tables, its incredibly counter productive and error prone. Instead use something else to specify the fields (ideally the source code of the api) and name each thing.
Then use simple Givens to create you things.
Now in your case you seem to be creating travelers. The behavior your Gherkin is documenting is the creation of travelers. HOW travelers are created and what their characteristics are have no place in this description of the behavior.
So your background steps become something like
Given there are foo travelers
an the implementation is something like
Given 'there are foo travelers' do
create_foo_travelers
end
and now you have translated you problem from
from
How do I do something incredibly stupid and difficult in Gherkin
to
How do I write some code to create travelers
This is the approach you should take to writing all scenarios when Cuking. The scenario should only document the WHAT and WHY of the behavior. Any details about HOW the behavior is implemented have no place in the scenario.
The true power of cuking is using natural language, naming and abstraction to make you cukes simple. Use these skills to delegate the complexity of HOW to more appropriate tools.