In order to use the Examples functionality in cucumber I think you'd have to do some significant metaprogramming that would probably reduce the maintainability and readability of your features. I'd probably accomplish this by wrapping you current steps in another step definition like so:
Scenario: do something
Given I load some data
Then expired cucumbers should give me diarrhea
and the define the step definitions
Then 'I load some data' do
@data = []
CSV.foreach("path/to/data.csv", headers: true) do |row|
@data << row
end
end
Then 'expired cucumbers should give me diarrhea' do
@data.each do |row|
step %Q|I eat number as #{row[:number]} cucumbers|
step %Q|the cucumber is produced at date as #{row[:date]}|
step %Q|the cucumber is expired|
setp %Q|I should have diarrhea|
end
end
The only problem with this is that if one scenario fails, it may take an extra debugging step to figure out which one is failing. Since these steps are run, more or less, under the hood. You could do this pretty easily by printing the row to STDOUT from the step definition:
Then 'expired cucumbers should give me diarrhea' do
@data.each do |row|
puts "row", row.inspect
step %Q|I eat number as #{row[:number]} cucumbers|
step %Q|the cucumber is produced at date as #{row[:date]}|
step %Q|the cucumber is expired|
setp %Q|I should have diarrhea|
end
end
That should give you some indication of which row is giving you trouble.
Erata: I understand your desire to be able to maintain a data sheet separate from the features so that someone like a Project Manager can come up with edge cases and then have those run against the behavior of the code. But I'd almost be more willing to allow them to edit the feature on github and allow CI to run those examples they added to the example table rather than do this approach. In either case its probably something good for regression, but probably really painful to develop code against. This type of testing is sort of the aim of http://fitnesse.org/ and that might be a project of inspiration for you.