What is the best practice for verifying a REST response that contains multiple relevant fields in cucmber/Gherkin? We are using scenario outlines so things are parameterized with examples tables.
Here are some approaches I've considered:
Simplest approach would be to just add each field as a column in the examples table. But this quickly became very unreadable as the examples table overflowed the width of the screen and we ended up with a almost a dozen steps in each scenario of the form: And the <fieldName> should be <value>. This is very verbose and obviously departs from the spirit of Gherkin being intended to resemble natural language.
Next I considered putting the response body as a whole into a file in JSON format and verifying it in a single step like And the response matches <file containing expected response>(examples table would just contain the path to the file). However, this makes it very opaque exactly what I am verifying in the test as the actual fields and data values are hidden away in another file. Furthemore, I've read that test steps should not be concerned with the exact format of the data (JSON, XML, or whatever).
After that I read this article uses a vertical table after the step to specify multiple fields. Resulting in something like this:
And the response contains:
| field1 | value1 |
| field2 | value2 |
However, I was unsure of how to parameterize this. Individual atomic values go into a column in the examples table but what about a whole other table? I looked into whether nested tables are supported but it seems like some people believe that to be unreadable and bad practice as well.
So, what is the general best practice for this scenario? For a parameterized scenario, what approach strikes the best balance between natural-language readability and precisely conveying your expectations?