Using variables in Cucumber Feature files?

Question

My team is testing a REST API using Cucumber. The steps make calls to the API while the scenarios have things like "Given I make call to XXX with JSON YYY".

Would it be very bad practice to set JSON variables in the background of feature files, and then manipulate/use them for the different scenarios? Many of our tests are using the same JSON objects with only 1-3 edited elements. I would like to do something like this for a scenario:

Given I update J element to K value in JSON YYY As <NewJsonVariable> ...

This seems like bad practice since Cucumber is itself a debatable tool for REST API testing, but now I'm wanting to put variables into the mix for the feature. However, I have some features that are 5-10k lines (broken into multiple files) and I estimate I could get this down to 500-1k lines and make it MUCH more readable. The only thing is that the test writer/reader now has to keep JSON variables in their head, but the tests are short enough that there would only be 2 or 3 variables at once.

Answer 1

The point of Cucumber is to allow plain English expression of WHAT is supposed to happen in each scenario inside the feature file. HOW that comes about is elaborated in the step files. You are putting far too much detail into your feature statements. This is going to be a nightmare to maintain so it likely will not be. With predicable results.

A scenario should probably go something like this:

Scenario The first thing our REST service does
  Given I have a REST service  
  When I connect with request "something" 
  Then I should get this result  

In the step files you do the set up with the matcher:

Given(/I have a REST service/i) do
   j_element = 'first value'
   . . .
end

The request is specified in the matcher:

When(/I connect with request "(.*)"/i) do |something|
  # Set new value
  j_element = something
  #send jason call 
  . . .
  return @result_set = visit( rest_api_path( j_element ) )
end

And the results are checked the in the matcher:

Then(/I should get this result/i) do
   check_result( result_set )
   . . .
end

Since passing instance variables around willy-nilly directly between methods is not considered good form you should define accessor methods in your step files to handle this in an elegant fashion.

def result_set()
  @result_set ||= 'nothing set yet'
end

Put tests that are used in multiple places inside their own methods and pass in what you want to check as an argument.

def check_result( result )
  assert . . .
  #or
  result.j_element.should . . .
 end

All the detailed stuff that you are presently putting into your feature files instead should be placed inside the do-end blocks that follow the matchers or in helper methods (like check_result and result_set). This makes understanding what your scenarios are supposed to accomplish much clearer to the reader and this will help you simplify your steps as well.

Answer 2

Cucumber is a tool for doing BDD not a test tool, and in particular not a tool for doing exhuastive testing. For the sort of tests you are doing, you would be much better using a unit test tool like RSpec. Because unit tests/specs are written in a programming language its a cinch to add variables, loops etc. to do lots of tests.

The reason to write features/scenarios is to describe behaviour, i.e. what you are doing, and perhaps more importantly, why you are doing it. Your scenarios really don't do this, instead they are documenting, in great detail, how you might use your api. To use Cucumber to develop your api, you should be writing scenarios in a much more abstract way e.g.

Scenario: I can create a book
  Given I am an author
  When I create a book
  Then I have a book

Note how this scenario has no detail whatsoever about how the book is created, no mention of json, not even a mention of an api.

TL/DR transfer your existing scenarios over to a unit test tool and introduce your variables, loops there. You can't/shoudn't 'program' in feature files.