Deprecate "calling steps from step definitions" functionality

[aslakhellesoy]

Summary

Calling steps from step definitions is one of the features I regret having added to Cucumber. It's like a poor man's implementation of subroutines (which all languages support natively) with the following drawbacks:

• Bad stacktraces
• Editor/IDE cannot spot errors
• Refactoring is painful

Using this functionality should print:

Calling steps from step definitions is deprecated and will be removed in the next major version. For a better alternative, follow this link: XXX

The XXX link should point to a page in the documentation explaining in more details how to use fiunctions/methods with Cucumber. It can be based on the explanation I gave in cucumber/cucumber-js#1232

[marnen]

You mean deprecating the step and steps methods? Please don’t do this. While I agree that it’s more generally useful to use methods to share code, there are some circumstances where Gherkin is the right tool for sharing code between steps.

One that comes up frequently for me is the notion of scoping output:

Then 'I should see "$text"' do |text|
  expect(page).to have_text text
end

Then 'I should see a cat GIF' do
  # code for locating cat GIF element
end

Then /^(.+) within (.+)$/ do |step_text, region_name|
  within selector_for(region_name) do
    step(step_text)
  end
end

...so that I can do Then I should see "hello" within the sidebar or Then I should see a cat GIF within the sidebar without much trouble. How would you advise doing this maintainably without step?

[luke-hill]

Use ruby's own send method if you want to metaprogram or program on the fly.

Use Helpers or Classes for specific pieces of reusable code

Use case / if logic to decide based on what text which class / helper to instantiate and use

[marnen]

@luke-hill:

Use ruby's own send method if you want to metaprogram or program on the fly.

Use Helpers or Classes for specific pieces of reusable code

I’m quite familiar with both these techniques, but I don’t see how either would be useful in the case I described. Do you?

Use case / if logic to decide based on what text which class / helper to instantiate and use

The Gherkin parser already does pretty much that, and I would rather reuse it than reimplement it. This idea seems like a step backwards to me.

If you need the problem stated in a more generic form: I have a modifier that I would like to be able to apply to any arbitrary Gherkin step from within the scenario. I only see one maintainable way to do that, and it’s this:

Then /^(.+) with modifier$/ do |step_text|
  with_modifier { step step_text }
end

How else would you propose to implement this, without maintaining a separate table of step definitions? I don’t understand how I can do this if step is removed, and I’d appreciate specific ideas, not just generic suggestions.

[luke-hill]

Helpers::ReUsableSteps.step_one
Helpers::ReUsableSteps.step_two
Helpers::ReUsableSteps.step_three

That's a primitive one that would allow you to call them. If they were module functions mixed into the World.
You could then call your steps based on the step_text so you just send call them.

Also I would advocate having one "mega-step", that does 10 different things, and actually have 10 small steps, even if portions are re-used. It makes debugging easier. And in-fact most of our open source stuff we're un-coupling steps, i.e. removing the areas that do 2 different things for 2 different steps that do 1 thing.

for your example you could do.

Then /^(.+) with modifier$/ do |step_text|
  with_modifier { Helpers::ReUsableSteps.send(step_text) }
end

[marnen]

@luke-hill No, that wouldn’t work at all. If you look again at my example, you’ll notice that step_text has the form of a Gherkin step (e.g. I should see "foo"), not a Ruby method name (e.g. step_one). That being the case, I don’t see how send would be helpful, unless you’re thinking of using method_missing to deal with receiving Gherkin text as a message...

...and if you are, then once again we need to map from Gherkin text to step definition, and so we’re right back to needing the step method.

Or did I miss something? I’d love to better understand what you had in mind, but so far it doesn’t seem like a suitable solution.

[luke-hill]

I don't want to go into exactly how to deal with your situation line by line, but you simply need a 1 to 1 mapping between what you capture and what you send.

It would work, because you're assuming you have to send a step which has spaces in, but you could sanitize that. There are many things you would perhaps need to do, unique to your situation.

Your step_text is simply a capture. How you translate that capture into something that can be sent you can decide (You could use a massive case, when statement for example).

Essentially the methodology you have of having a "master step" which then delegates to a multitude of other steps is something I would disuade in most circumstances, it's too hard to triage, too taxing for newcomers and relies heavily on almost a bus-factor style approach where a few siloed team members know everything. It's currently an area in aruba we are "un-DRYing" if you like to think of it that way.

See cucumber/aruba#666 perhaps for a code explanation?

EDIT: This has massively gone off tangent from the original placeholder, which is to deprecate the usage of the steps and step methods. Which will be done at some point during the v4 lifecycle I imagine.

[marnen]

@luke-hill:

I don't want to go into exactly how to deal with your situation line by line,

I’ll admit I was sort of hoping for that. I’m very experienced with both Cucumber and Ruby, but I can’t figure out how to implement your suggestions in a way that makes sense. However, if that’s more appropriate for the mailing list or something, we can take it there.

but you simply need a 1 to 1 mapping between what you capture and what you send.

Correct. And that’s what the step method already gives me, which is why I don’t want to see it go away without a suitable replacement in place.

Your step_text is simply a capture. How you translate that capture into something that can be sent you can decide (You could use a massive case, when statement for example)

Are you seriously proposing that? The Gherkin step definitions already provide a perfectly suitable translation. A massive case statement would just reimplement that, for no benefit that I can see.

In other words: I already know how I want to translate that capture. I want to translate it the exact same way that Gherkin would if it were a step by itself. That’s why I think I need step here. Is there another way to achieve that goal without step? If there were, I’d use it, but so far I’m not seeing it.

This has massively gone off tangent from the original placeholder, which is to deprecate the usage of the steps and step methods.

As far as I can tell, this is exactly on topic for that. The whole point of my comments here is that we shouldn’t deprecate those methods, because they make possible some very useful abstractions that AFAIK can’t be implemented in any other way.

I hope I’ve explained my use case pretty clearly here, but all I’ve gotten is rather glib generic answers that won’t actually work in the situation I described as far as I can tell.

I find this extremely frustrating. If the core team is bound and determined to deprecate step, then please help me find an alternative for the one use case I know of where it seems to be indispensable.

Which will be done at some point during the v4 lifecycle I imagine.

Then if another workable solution is not provided, I’ll either have to abandon Cucumber at that time (which would be a huge pity) or maintain my own fork or plugin (which I really don’t want to put the time into doing).

[luke-hill]

Everyone who works on cucumber are volunteers. Whilst there is a small amount of funding available for fixing and tracking issues, looking for custom solutions is unlikely without a serious injection of funds. There is an OpenCollective account visible here: https://opencollective.com/cucumber

In short, the 2 key takeaway points here are you can re-abstract your use cases in a language specific way see cucumber/cucumber-js#1232 for more info (Which I see you've commented on).

Also that in order to maintain this abstraction, it provides the user with no discernable benefits, and just a mountain of issues. Using a language specific abstraction would only provide benefits, and no drawbacks.

Now as to your specific use case. I can't comment on it specifically, but if I was to hazard a guess, you may be in a situation similar to what I had at a previous company and/or what we have in aruba (step is being called in lots of places).

Refactoring a large app is something which is an arduous task I admit, but keeping it as a monolith has issues. Here as I see it you have a simple choice (Both are valid options)

• Commit to the work to refactor out the old legacy code
• Maintain the legacy code and don't refactor

Again both are valid. However with the first case, you gain a (arguable), advantage that you can use the latest versions. In the same way that maintaining a Windows95 OS is viable, but don't then expect to be able to run NVidia Turing technology with 16-AA (Not sure if you get this reference, apologies if not).

If you are very experienced with Ruby, then you should know that using language specific abstractions, such as Helpers, Classes and more indepth stuff such as Singletons or Anonymous classes, all come with large stacktraces and good debugging tools. I know (From reasonable personal experience), that using steps especially ones with 5+ calls inside a single step with interpolated parts and metaprograming, only leads you to a highly coupled system.

We are not advocating for one minute that our way is the only way or the highway. What we are advocating is we believe this is the way the software "should" work. People are completely within their rights to disagree, however, we would like users to attempt to use workarounds where explained, or try to understand the logic behind our decision-making.

In this instance, the logic is simple, deprecate something which is old, and not best served in Ruby (It has already been removed from other languages). You can use a 1-1 mapping as I've mentioned to solve your issue. But short of doing the work for you (Which I'm sure you'd expect, would be perhaps crossing a line), you need to perhaps spike a few different solutions for yourself.

If you want further reading, check a lot of the aruba library between around 0.11 and 0.14.1 and then compare it to 0.14.11 and 1.0.pre versions. We're actually uncoupling steps, not re-coupling them. This sounds counter productive, but sometimes in tests, less-DRY is better

I hope this has explained things better. But if not I suggest doing some reading into some of the points, checking out the code areas I've suggested or maybe (Ability in other languages not known), checking Java or other versions of cucumber to see how other people have conquered this issue (It's not just a ruby issue)

[marnen]

@luke-hill:

Everyone who works on cucumber are volunteers.

I’m aware of this, of course. And thanks for your time and energy!

you may be in a situation similar to what I had at a previous company and/or what we have in aruba (step is being called in lots of places).

Nope. I’m in exactly the situation I said I was in: I have one place in the codebase where I apparently need to use step, for reasons that I’ve explained elsewhere in this thread. I don’t like step that much myself, and I’d be happy if I could get completely rid of it, but I don’t see how.

I have a feeling we’re talking past each other in this regard, because you keep suggesting solutions that are not relevant to my use case, and you have made several guesses about my use case that have nothing to do with anything I’ve said about it. I’ll be happy to clear up any further confusion about what I’m trying to do, but I don’t know how else to say what I’ve already said.

If you are very experienced with Ruby, then you should know that using language specific abstractions, such as Helpers, Classes and more indepth stuff such as Singletons or Anonymous classes, all come with large stacktraces and good debugging tools.

I’m aware of that. It is not relevant to my question, because (1) I have never found debugging these steps to be a problem and (2) as far as I can tell, those abstractions do not provide me what I need here. step does.

I know (From reasonable personal experience), that using steps especially ones with 5+ calls inside a single step with interpolated parts and metaprograming, only leads you to a highly coupled system.

That’s not what I’m doing. That’s not something I’d ever do. Please read again my description of the technique I am using. I am making one call to step. One. And I’d love to get rid of it, but I haven’t found a way to, and your suggested workarounds are starting to seem to confirm that there isn’t one.

We are not advocating for one minute that our way is the only way or the highway.

From my perspective, that sure does seem like what is going on here. You (the core team, not you personally) are trying to remove something that works well and doesn’t have a good alternative, because it seems like it “shouldn’t” be in there.

You can use a 1-1 mapping as I've mentioned to solve your issue.

step is the 1-1 mapping I need. How can I replace it without building a complete duplicate of the Gherkin step definitions table?

But short of doing the work for you (Which I'm sure you'd expect, would be perhaps crossing a line), you need to perhaps spike a few different solutions for yourself.

I’m not asking you to do my work for me. But: when you deprecate a feature that people have come to rely on, the onus is on you to suggest an alternative approach that actually replaces the deprecated feature. Certainly I’d do that if anyone asked a similar question about a deprecation in any of the libraries I maintain.

The crux of my problem is that I want to do the following:

1. Capture some text.
2. Map the captured text to a block of code in exactly the same way that Gherkin does.
3. Execute that block in a particular context.

1 and 3 are trivial. I cannot see how to do 2 without step. This is the part for which I am once again asking for a suggestion, or recommending that step be taken off the deprecation list.

[luke-hill]

1. Capture the text in the same way
   1.1) Either during 1, or before 2, have some transformer, which maps the text to the helper / class / singleton you want. Examples could be rolling your own, using activesupport, using a class extension / monkeypatch or a wrapper method i.e. sanitize(gherkin capture)
2. Once transformed, map this text and call your new functionality, either using send or directly having the new methods defined
3. If you're looking to pass a block through the caller chain, then the block must be defined in your steps. So either you need to re-define your block in the new method signature, or pass it through using the &block / block_given? methods which will help here.

[badeball]

I'm sad to see this go away, for the same reason as @marnen has outlined.

Either during 1, or before 2, have some transformer, which maps the text to the helper / class / singleton you want.

As @marnen has already attempted to explain - this is what we're already doing with Cucumber. You seem to be proposing we implement another mapping between natural text and code, mimicking that we already have (with Given / When / Then + Regexp), which seems so non-sensical to me.

I can appreciate the argument that this feature is hard to maintain, but you're not succeeding in proposing an alternative solution.

[luke-hill]

What you currently do is the following.

1. Capture text
2. Use a mapping - "regex string match"
3. From this 1-1 match, fire a new method (These are the cucumbers internals which are not exposed, and how they are work is confusing to explain, not 100% clear and completely abstract from the MRI or JRuby)

What I am proposing is this

1. Capture text
2. Use a mapping (Lets say for arguments snake case, because I've tried to hand-hold a bit and not had much luck
3. From this 1-1 match, fire a new method (These are now 100% traceable and better than anything previously).

Given I'm a healthy contributor, I'm aware this sounds bad, but you need to trust me that the new methodology is better. I'm speaking as someone who had at a previously company a healthy amount of step usages, and the stacktraces in the cucumber html reports were always a little bit messy.

Also I've attached a rudimentary code example.

Previously

# code omitted
step captured_regex
# code omitted

Now

# code omitted
Kernel.public_send MyHelper::Whatever::OtherNamespace.snake_case captured_regex
# code omitted

EDIT: There are also about 3 or 4 other ways of doing it, if you don't want to mix in the method to the global NS

Obviously I've made up a long namespace to illustrate it could be whatever.

I'm not keen on this backwards and forwards motion because it's all theoretical, could you maybe have a go at doing it, or perhaps illustrate with a git repo why it wouldn't work. Sometimes in learning (Using something called the VAK model), people are not understanding one particular way of explaining, so maybe an alternative is in order?

[marnen]

@luke-hill:

but you need to trust me that the new methodology is better

No, we don’t need to trust you. You need to tell us why it is better. Right now, it seems like extra work for no benefit, at least for our use case.

I'm speaking as someone who had at a previously company a healthy amount of step usages, and the stacktraces in the cucumber html reports were always a little bit messy.

That has not been my experience with my step usage patterns.

or perhaps illustrate with a git repo why it wouldn't work.

As @badeball and I have said, it wouldn’t work because it duplicates the mapping that Cucumber already provides, and because it’s not general. That is, with your snake_case approach, I have to define a new method every time I have new captured text to map. That defeats the purpose of doing this in the first place. Remember, I literally want to be able to do Then any arbitrary step with modifier and have it use the already existing Cucumber mappings for Then any arbitrary step. You are not providing a solution that has that flexibility.

Again, my canonical case is the one I already described, that of Then I should see "foo" within the sidebar. If you’d like to see it in action, take a look at https://github.com/marnen/erogatio/blob/master/features/step_definitions/web_steps.rb#L27 and https://github.com/marnen/erogatio/blob/master/features/enter_payment_for_work_units.feature#L20. Note in particular the use of two different steps in When/Then <step> within the work unit in that scenario. In principle, I could use any step there without additional coding, and that’s the important feature that your solution (AFAIK) fails to give me.