Each time a step_match is invoked it uses the same object as the step argument

[tooky]

As reported by Daniel Esponda on the ML

I've created an example of this for cucumber 2.0.

Cucumber 2.0 is different because the step arguments are frozen, but I do think its unexpected that we get the same === object each time a particular step match is invoked. Is it also slightly problematic if users can't modify step arguments because they are frozen?

[tooky]

@mattwynne - I've change this behaivour in this PR so that each time a step definition is invoked it gets copies of the step_match args. I think this is probably less surprising behaviour, and also prevents the step_match args getting fiddled with and breaking the pretty formatter. WDYT?

[diabolo]

I'm puzzled by why we are not getting a new object each time the step is called. If I understand correctly it seems that in the example we create one password object and then set it to different values for each row in the table. So we are sharing on object across test instances, this doesn't feel right. Could you explain why we are doing this.

Many thanks :)

[tooky]

@diabolo you've hit on the core thing. I agree its surprising that each time you invoke a step definition with the same matching step the arguments passed are the same object.

This is happening because when the .feature files are parsed we create the step_matches, and we reuse the same match if we come across it again. This step_match object already has its arguments cached, and the current code is just passing them in as-is in when it invokes the block from the step definition.

(Well it's sending dup to the collection of args, but that just gives you a new Array, the objects inside are the same).

This proposed change ensures that every time we invoke a step_definition we invoke it with new objects as the block parameters. I think this is less surprising.

[diabolo]

@tooky thanks for the explanation, much appreciated.

[mattwynne]

I haven't ready up on this issue fully yet, but it strikes me that if we were using immutable values for the arguments, this wouldn't matter. But did I miss something? Transforms maybe?

[tooky]

Immutable objects stop there being problem if people try and modify the object, but I think the principle of least surprise is to pass a fresh object every time the step def is invoked. Let people modify it if they want, it won't live longer than the end of the step def.

[mattwynne]

This seems a bit crude. What about args.map &:dup - we control the types that would be in the array, don't we?

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

[tooky]

@aslakhellesoy here's some history regarding deep clone of step arguments #453 and #1275 are interesting related issues