Negate rule is ambiguous?

I feel your pain. I had to work around some quirky Gherkin issues on some of my tests, too.

("The Quirky Gherkins" would make a great band name, btw.)

My general strategy when I encountered Gherkin issues was to add new rules. For instance, in this case, instead of using {word}, I would create a new pattern called (e.g.) {variable} with explicit matching rules. Whether you can do this or not might depend on which implementation of Cucumber you're using... I was using the Ruby version.

- Jamis

Well, that worked ........... for a while.

Now I think I'm properly blocked? I'm up to:

Scenario Outline: A ray intersects a cube
   Given c ← cube()
   And r ← ray(<origin>, <direction>)
   When xs ← local_intersect(c, r)
   Then xs.count = 2
   And xs[0].t = <t1>
   And xs[1].t = <t2>

Given c ← cube() forces me to accept c as a shape_var... and then I get:

"c.transform = identity_matrix" matches more than one step definition:
     "c.transform = {matrix_var}" in CameraStepDefinitions.<init>(CameraStepDefinitions.kt:53)
     "{shape_var}.transform = {matrix_var}" in ShapeStepDefinitions.<init>(ShapeStepDefinitions.kt:99)

Now I'm kind of at a loss. Short of editing the text of the scenario, which up to now I have been trying not to do.

That I managed to get past previously. The current problem (as stated above) is more serious, because I have two steps which are both "c.transform = {matrix_var}", but "c" in one is supposed to be a Camera, while "c" in the other one is supposed to be a Cube. I can't see any way to distinguish those two cases as the only differing part of them is what matrix happens to be passed on the RHS.

So at that point I more or less gave up on implementing the scenarios as written, and started rewriting the scenarios to remove ambiguity. Editing the scenarios felt like cheating, but given the situation I couldn't see an alternative.

But I could see two ways to rewrite the scenarios to remove ambiguity:

1. Change the name of the variable (this is what I've done in my scenarios):

• "When camera.transform = {matrix_var}"
• "When shape.transform = {matrix_var}"

2. Spell things out a bit more like a real scenario:

• "When camera c has transform set to {matrix_var}"
• "When shape c has transform set to {matrix_var}"

But what I'm really curious about is whether there is a way to do this _without_ modifying the scenario. Do I extract a Transformable interface from both types and then refactor out all step definitions for setting/getting the transform into a TransformableStepDefinitions? Or is there another way to go about this? How did others approach this?



(Incidentally, I found another workaround for that issue I posted on StackOverflow as well - I had some other scenario later on where I ended up wanting to reuse "cube\\(\\)", "sphere\\(\\)" so I turned it into a parameter type. That made it possible to put it into cucumber syntax and removed the need for the regex workaround in the step definition itself.)

That's an interesting way to go about it. I had gone with the path of each property as a different given, like


Given("{shape_var}.transform ← {transform}") { shapeVar: String, transform: Matrix ->

   shapes[shapeVar]!!.transform = value

}


Which makes each step much easier to understand but does run into issues if two things share the same name.