[jms_]

Given that the system these scenarios test also manage state, it's not surprising that the step definitions used in the scenario also need to manage some form of state.

While it's advisable to avoid unnecessary state between steps in a scenario like this, removing all state limits the ability for a scenario to express the intent the author speaks about.

[IanCal]

One option is to move the state to be explicit in the call to the step, which means the test becomes an example rather than a general rule (although that's what it always was, now it's just a bit clearer). It also means the steps can be reused, rather than having steps with dependencies (which aren't specified anywhere or statically enforced).

> removing all state limits the ability for a scenario to express the intent the author speaks about.

However, writing them like that means each step moves further away from what it says it's doing. The more you do this, the more you might as well not execute them and go and write more examples.

[jfrisby]

To use your example -- how desirable is it to generalize "I change my name" to something "reusable"?

I'm finding these days that a pairing of .feature to corresponding step definition file allows for fluid language, simple step definition code, and well-compartmentalized messes (as opposed to the big ball of mud that Cucumber step definitions often become). Code reuse can happen through test helper classes that are called from step definitions as needed. (FactoryGirl would be an example of a very generalized test helper class, in my mind -- but more system-specific ones can be handy, albeit one wants to avoid making stateful / complex test helper code!)