Is calling steps from step definitions as bad as I think?

[Andrey Botalov]

I'm just seeing tests where there are almost no modules at all. All reusage of code is done using calling steps from step defintions. For that matter step defintions were sometimes created for the sole matter to be invoked from other step defintions.

Also calling stepdefs from stepdefs has the following disadvantages:

1. If scenario will fail you will get only the last invoked stepdef in the output. It's very hard to see from which stepdef this stepdef was called

2. It's harder to find stepdef that is called than method of Module

Is there any benefit in existance of calling steps from step definitions? Maybe, it should be deprecated

[George Dinwiddie]

Andrey,

It is generally deprecated. Many people find no use for the technique at
all. I'm one of those who find limited use,
- (most importantly) as a path to refactoring from imperative to
declarative scenarios, and
- as a means for those with scripting knowledge but not programming
knowledge to be productive in creating new variations.

It is, of course, a technique that's fraught with peril. As you note,
it's very hard to tell what's happening when something goes wrong. Also,
gherkin step definitions lack the power of a programming language.
Finally, people tend to forget that they ARE programming when they write
these step definitions. Of course, they are also programming when they
write the scenarios, and they're mostly oblivious to that fact, also.

- George

--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Rob Park]

On Tue, Aug 7, 2012 at 11:04 AM, George Dinwiddie <li...@idiacomputing.com> wrote:

Andrey,

On 8/7/12 12:27 PM, Andrey Botalov wrote:

I'm just seeing tests where there are almost no modules at all. All
reusage of code is done using calling steps from step defintions. For
that matter step defintions were sometimes created for the sole matter
to be invoked from other step defintions.

Also calling stepdefs from stepdefs has the following disadvantages:
1. If scenario will fail you will get only the last invoked stepdef in
the output. It's very hard to see from which stepdef this stepdef was called
2. It's harder to find stepdef that is called than method of Module

Is there any benefit in existance of calling steps from step
definitions? Maybe, it should be deprecated

It is generally deprecated. Many people find no use for the technique at all. I'm one of those who find limited use, 

 - (most importantly) as a path to refactoring from imperative to declarative scenarios, and
 - as a means for those with scripting knowledge but not programming knowledge to be productive in creating new variations.

+1 

It is, of course, a technique that's fraught with peril. As you note, it's very hard to tell what's happening when something goes wrong. Also, gherkin step definitions lack the power of a programming language. Finally, people tend to forget that they ARE programming when they write these step definitions. Of course, they are also programming when they write the scenarios, and they're mostly oblivious to that fact, also.

Interestingly, I've never run into problems debugging these.  Not sure why, because I've read the stories.

Perhaps it's a combination of limited use and RubyMine. 

 - George

//rob

[Andrew Premdas]

No there is no benefit.

It shouldn't/can't be deprecated because there are large numbers of cukers who don't realise there is no benefit.

All you can do is refactor the steps to remove the nesting, its tedious, but doable and hopefully when its done people will see the benefits

All best

Andrew

 

--
-- Rules --
 
1) Please prefix the subject with [Ruby], [JVM] or [JS].
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
3) If you have a question, don't reply to an existing message. Start a new topic instead.
 
You received this message because you are subscribed to the Google Groups Cukes group. To post to this group, send email to cu...@googlegroups.com. To unsubscribe from this group, send email to cukes+un...@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en
 
 

--

------------------------

Andrew Premdas

blog.andrew.premdas.org

[Jeff Nyman]

On Tuesday, August 7, 2012 11:27:31 AM UTC-5, Andrey Botalov wrote:

Is there any benefit in existance of calling steps from step definitions? Maybe, it should be deprecated

 

 

We've actually used this concept where I work and have found it really nice, but it can offer some challenges. Unlike most people, I'm not either-or about it. It has positives and negatives. As an example, let's say I have a simple clause like this:

 

 

Scenario: The Lucid customer must exist
  * the default customer exists

 

Obviously I'm making this contrived a little bit. But that might look like this behind the scenes:

 

 

Given (/^the default customer(?: exists)?$/) do
  step %{I login as "clinical administrator"}
  step %{I go to the customers list page}
  step %{I filter on "Lucid"}
  step %{I search the list for "Lucid"}
end

 

Here "the default customer" is and always will be Lucid by definition, which is why that information is hard-coded here. Further, only clinical administrators can do anything customers. Notice how first-person statements are only done in the test (step) definitions. Information at the scenario level is more generically stated. Each of those steps looks something like this:

 

 

When (/^I login as (?:a |the )?"([^"]*)"$/) do |role|
  on_view(LoginPage).perform_login(user_data_for(role))
end

 

When (/^I go to the (.*) list page$/) do |entity|
  on(Navigation).navigate_to(entity)
end

 

Given (/^I filter on "(.*?)"$/) do |text|
  during(Filtering).start_filter
  on(FilterPage).filter_by(text)
end

 

This has lead to a lot of success for us in terms allowing test writers to create composable sets of steps. We also have a little logic that can pull out all the "I do this" type stuff so that it outputs the exact steps that were taken if the scenario fails. Those steps are put into a bug report exactly as is and it reads just as if a manual tester had entered the steps in the report. We have also used this to train new testers on an application and for demonstrations given by marketing.

 

This may not be the "right" way that some people envisioned for Cucumber's use and I know there are different ways to do it that would require none of this. So I'm not putting this up here for people to tell me how wrong they think I am for doing it this way. Rather, I just wanted to give a specific example rather than "Yes, it's fine to do this" or "No, you shouldn't do this."

 

I think the benefit of a tool like Cucumber is that it (currently anyway) lets you work the way you want to work, even if that doesn't fit how others feel things "should" be. I hope that philosophy continues with Cucumber development.

 

- Jeff