[Cucumber:6329] Expanding nested steps on execution

[Eric Pierce]

I really dig Cucumber's support for building complex steps out of
simpler ones, but sometimes I wish there was an option to "expand"
those inner steps when they are executed, especially those times when
I have a bug in an inner step--the backtrace can be pretty useless.

What I would like to see is either a command-line option, or something
similar to the 'steps' method (maybe 'macro'?) with a multiline
string, such that when I have a feature like this:

Given ABC
Then DEF

And step definitions:

Given /^ABC$/ do
macro %Q{
Given A
And B
And C
}
end

Then /^DEF$/ do
macro %Q{
Then D
And E
And F
}
end

When I run this feature, I'd like to see this output:

Given A
And B
And C
Then D
And E
And F

Or even:

Given ABC
Given A
And B
And C
Then DEF
Then D
And E
And F

In other words, the ABC and DEF steps are just stand-ins for the fully-
expanded inner steps. Nearly identical to the 'steps' syntax, but
evaluated as if the inner steps had been explicitly included in
the .feature file.

The topic of macros was touched upon in an older thread ("Mixing ruby
code and steps %Q{ } in a step definition?") but I have not seen
mention of expanding the steps in the output as I've described above.

I've started poking through the Cucumber code and thinking of ways to
implement this, but I am wondering if anyone else has interest in such
a feature, and also whether it has been discussed or attempted before.

Thoughts?

[Matt Wynne]

cheers,
Matt

matt-***@public.gmane.org
07974 430184

Post by Eric Pierce
I really dig Cucumber's support for building complex steps out of
simpler ones, but sometimes I wish there was an option to "expand"
those inner steps when they are executed, especially those times when
I have a bug in an inner step--the backtrace can be pretty useless.
What I would like to see is either a command-line option, or something
similar to the 'steps' method (maybe 'macro'?) with a multiline
Given ABC
Then DEF
Given /^ABC$/ do
macro %Q{
Given A
And B
And C
}
end
Then /^DEF$/ do
macro %Q{
Then D
And E
And F
}
end
Given A
And B
And C
Then D
And E
And F
Given ABC
Given A
And B
And C
Then DEF
Then D
And E
And F
In other words, the ABC and DEF steps are just stand-ins for the fully-
expanded inner steps. Nearly identical to the 'steps' syntax, but
evaluated as if the inner steps had been explicitly included in
the .feature file.
The topic of macros was touched upon in an older thread ("Mixing ruby
code and steps %Q{ } in a step definition?") but I have not seen
mention of expanding the steps in the output as I've described above.
I've started poking through the Cucumber code and thinking of ways to
implement this, but I am wondering if anyone else has interest in such
a feature, and also whether it has been discussed or attempted before.
Thoughts?

Andrew, are you going to hold up your sign? ;)

There's been quite a bit of discussion about this before. A lot of us feel that nesting steps like this is a bit of an anti-pattern. Search the group for posts by Andrew Premdas and you'll get the picture.

This isn't obviously a great reason, but I also suspect this would be pretty awkward to build, and right now the internals of Cucumber are gradually being cleaned up. Until that's done it's hard for us to really even think about building this kind of thing.

cheers,
Matt

http://blog.mattwynne.net

[aslak hellesoy]

Post by Matt Wynne
cheers,
Matt
07974 430184

Post by Eric Pierce
I really dig Cucumber's support for building complex steps out of
simpler ones, but sometimes I wish there was an option to "expand"
those inner steps when they are executed, especially those times when
I have a bug in an inner step--the backtrace can be pretty useless.
What I would like to see is either a command-line option, or something
similar to the 'steps' method (maybe 'macro'?) with a multiline
Given ABC
Then DEF
Given /^ABC$/ do
macro %Q{
Given A
And B
And C
}
end
Then /^DEF$/ do
macro %Q{
Then D
And E
And F
}
end
Given A
And B
And C
Then D
And E
And F
Given ABC
Given A
And B
And C
Then DEF
Then D
And E
And F
In other words, the ABC and DEF steps are just stand-ins for the fully-
expanded inner steps. Nearly identical to the 'steps' syntax, but
evaluated as if the inner steps had been explicitly included in
the .feature file.
The topic of macros was touched upon in an older thread ("Mixing ruby
code and steps %Q{ } in a step definition?") but I have not seen
mention of expanding the steps in the output as I've described above.
I've started poking through the Cucumber code and thinking of ways to
implement this, but I am wondering if anyone else has interest in such
a feature, and also whether it has been discussed or attempted before.
Thoughts?

Andrew, are you going to hold up your sign? ;)
There's been quite a bit of discussion about this before. A lot of us feel
that nesting steps like this is a bit of an anti-pattern.

For the record - I'm one of those people. Here is my workflow:

Whenever I feel the temptation to use a step Given /something super useful/
in another stepdef I extract the body of Given /something super useful/ to a
CukeHelpers#something_super_useful module method.

Then I World(CukeHelpers)

Now I can invoke a plain old method from my stepdef instead of invoking a
step

Question to the group: What benefits do you see in invoking steps over
invoking methods?

Aslak

Search the group for posts by Andrew Premdas and you'll get the picture.

Post by Matt Wynne
This isn't obviously a great reason, but I also suspect this would be
pretty awkward to build, and right now the internals of Cucumber are
gradually being cleaned up. Until that's done it's hard for us to really
even think about building this kind of thing.
cheers,
Matt
http://blog.mattwynne.net
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[Eric Pierce]

Post by Matt Wynne
There's been quite a bit of discussion about this before. A lot of us feel
that nesting steps like this is a bit of an anti-pattern.

Now that I've done some more sifting through the archives, I see that
this topic has come up in the past, and that there are conflicting
opinions about whether step-nesting is even a good idea in the first
place. One common answer is to use helper methods added to World, but
I can't shake the feeling that this doesn't address the problem. When
someone asks "How can I make nested steps better?" the reply is often
"Don't use nested steps."

Post by Matt Wynne
Question to the group: What benefits do you see in invoking steps over
invoking methods?

I think the clear advantage of steps is their readability by non-
programmers. To me, step definitions are basically general-purpose
functions that happen to have a more readable and natural-language
invocation syntax. As a programmer, of course I would prefer writing
this:

login("alice", "1234")

over this:

When %{I login as "alice" with password "1234"}

But the latter form can go straight into a .feature file, while the
former must be wrapped in a step definition. Sure, I can do this:

When /^I login as "(.+)" with password "(.+)"$/ do |username,
password|
login(username, password)
end

Then shunt the "login" helper method to some other place, but that
doesn't seem very DRY, and it's quite possible that I want my "login"
method to itself be built from pre-existing steps, such as the ones
provided by Webrat or Capybara:

When %{I fill in "Username" with "#{username}"}
And %{I fill in "Password" with "#{password}"}
And %{I press "Login"}

My thinking is that steps should be kept Gherkin-ized to as low a
level as possible, for a few reasons:

- Readable by all parties
- I can build high-level step definitions out of low-level steps
- I can build features using low-level OR high-level steps

Where this breaks down (at least with the current architecture) is
that when I put high-level steps in my .feature, a lot of the low-
level stuff becomes opaque. This is one of the objections often raised
against nested steps in general--that they are harder to understand
and debug. This is my objection too; I would like them to be easier to
understand and debug, and I think a "macro" concept would help here.

What I have in mind could be implemented through some kind of pre-
processing of the .feature file. If I have step definitions that
consist purely of other steps (as I often do), I would like the option
to mark those as "macros". Thus, when pre-processing:

Given ABC
Then DEF

those macros would get expanded to the full low-level steps before
being evaluated. I think this would greatly mitigate the "hard to
understand" and "difficult to debug" issues, while still making it
possible to write DRYer features.

[Mike Sassak]

Post by Eric Pierce

Post by Matt Wynne
There's been quite a bit of discussion about this before. A lot of us feel
that nesting steps like this is a bit of an anti-pattern.

Now that I've done some more sifting through the archives, I see that
this topic has come up in the past, and that there are conflicting
opinions about whether step-nesting is even a good idea in the first
place. One common answer is to use helper methods added to World, but
I can't shake the feeling that this doesn't address the problem. When
someone asks "How can I make nested steps better?" the reply is often
"Don't use nested steps."

Post by Matt Wynne
Question to the group: What benefits do you see in invoking steps over
invoking methods?

I think the clear advantage of steps is their readability by non-
programmers. To me, step definitions are basically general-purpose
functions that happen to have a more readable and natural-language
invocation syntax. As a programmer, of course I would prefer writing
 login("alice", "1234")
 When %{I login as "alice" with password "1234"}
But the latter form can go straight into a .feature file, while the
 When /^I login as "(.+)" with password "(.+)"$/ do |username,
password|
   login(username, password)
 end
Then shunt the "login" helper method to some other place, but that
doesn't seem very DRY, and it's quite possible that I want my "login"
method to itself be built from pre-existing steps, such as the ones
 When %{I fill in "Username" with "#{username}"}
 And %{I fill in "Password" with "#{password}"}
 And %{I press "Login"}
My thinking is that steps should be kept Gherkin-ized to as low a
 - Readable by all parties
 - I can build high-level step definitions out of low-level steps
 - I can build features using low-level OR high-level steps
Where this breaks down (at least with the current architecture) is
that when I put high-level steps in my .feature, a lot of the low-
level stuff becomes opaque. This is one of the objections often raised
against nested steps in general--that they are harder to understand
and debug. This is my objection too; I would like them to be easier to
understand and debug, and I think a "macro" concept would help here.
What I have in mind could be implemented through some kind of pre-
processing of the .feature file. If I have step definitions that
consist purely of other steps (as I often do), I would like the option
 Given ABC
 Then DEF
those macros would get expanded to the full low-level steps before
being evaluated. I think this would greatly mitigate the "hard to
understand" and "difficult to debug" issues, while still making it
possible to write DRYer features.

I disagree. The advantage of *Gherkin* is that it is readable by
non-programmers. The implementation language is the implementation
language, and if it is constrained by requirements that it, too, be
readable by non-programmers, we're all going to be in a lot of
trouble. If your client is asking what is happening in a given
scenario or why, then that is a sign that the scenario is missing some
information that it doesn't currently include. This can change between
clients. Some clients might insist the value is in the minute
interactions, and perhaps it is. Others might be fine with higher
level stuff. Still others might want a mix. It's up to you to figure
out. Having said that, Cucumber should still have opinions, in my
opinion, about the best way to make it easy to strike that balance.

This brings me to DRY, and helper methods. I think many people believe
that a step definition has the same responsibilities and attributes as
a method or function; that it is "a method with a weird name". This is
a mistake. Step defs have one major responsibility: to map the
language of your domain to your language of implementation. This does
not and can not happen anywhere else. (Currently, at least.) The
responsibility of methods (or functions, or whatever), on the other
hand, is to group conceptually related blocks of code. This is a
subtle but crucial difference--I think the one that trips people up.
It is possible, of course, to include code in your step defs that
manipulates your application, but that is an implementation detail
that makes it easy to get started. It is not *why* step defs exist.
This is why having a step def call a helper method is DRY. DRY isn't
about mechanical duplication of bytes, it is about duplication of
concepts and responsibilities. Step defs and helper methods have two
distinct responsibilities and embody two different concepts, which is
why using both isn't a violation of the DRY principle.

To repeat: steps aren't methods. They are mappers. They're *almost*
named functions, and this is what causes confusion, but Cucumber isn't
nearly close enough to proving Greenspun's 10th Rule [0] to start
treating step definitions as first-class functions in their own right.

HTH,
Mike

[0] http://en.wikipedia.org/wiki/Greenspun's_Tenth_Rule

Post by Eric Pierce
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

[George Dinwiddie]

Alas, poor Cucumber, I knew him well.

Post by Mike Sassak

Post by Eric Pierce

Post by Matt Wynne
There's been quite a bit of discussion about this before. A lot of us feel
that nesting steps like this is a bit of an anti-pattern.

Now that I've done some more sifting through the archives, I see that
this topic has come up in the past, and that there are conflicting
opinions about whether step-nesting is even a good idea in the first
place. One common answer is to use helper methods added to World, but
I can't shake the feeling that this doesn't address the problem. When
someone asks "How can I make nested steps better?" the reply is often
"Don't use nested steps."

Post by Matt Wynne
Question to the group: What benefits do you see in invoking steps over
invoking methods?

I think the clear advantage of steps is their readability by non-
programmers. To me, step definitions are basically general-purpose
functions that happen to have a more readable and natural-language
invocation syntax. As a programmer, of course I would prefer writing
login("alice", "1234")
When %{I login as "alice" with password "1234"}
But the latter form can go straight into a .feature file, while the
When /^I login as "(.+)" with password "(.+)"$/ do |username,
password|
login(username, password)
end
Then shunt the "login" helper method to some other place, but that
doesn't seem very DRY, and it's quite possible that I want my "login"
method to itself be built from pre-existing steps, such as the ones
When %{I fill in "Username" with "#{username}"}
And %{I fill in "Password" with "#{password}"}
And %{I press "Login"}
My thinking is that steps should be kept Gherkin-ized to as low a
- Readable by all parties
- I can build high-level step definitions out of low-level steps
- I can build features using low-level OR high-level steps
Where this breaks down (at least with the current architecture) is
that when I put high-level steps in my .feature, a lot of the low-
level stuff becomes opaque. This is one of the objections often raised
against nested steps in general--that they are harder to understand
and debug. This is my objection too; I would like them to be easier to
understand and debug, and I think a "macro" concept would help here.

I've not looked at the ramifications of a "macro" concept here, but I
agree with the rest for readability, and ease of use by people who don't
consider themselves programmers (and some programmers, too).

Post by Mike Sassak

Post by Eric Pierce
What I have in mind could be implemented through some kind of pre-
processing of the .feature file. If I have step definitions that
consist purely of other steps (as I often do), I would like the option
Given ABC
Then DEF
those macros would get expanded to the full low-level steps before
being evaluated. I think this would greatly mitigate the "hard to
understand" and "difficult to debug" issues, while still making it
possible to write DRYer features.

I suspect that it would be possible to maintain the text of the lower
level sub-steps without a macro concept, but I've not looked at the
current cucumber implementation. The readability of nested steps seems
to be the one place where Fitnesse/Slim surpasses Cucumber, IMO.

Post by Mike Sassak
I disagree. The advantage of *Gherkin* is that it is readable by
non-programmers. The implementation language is the implementation
language, and if it is constrained by requirements that it, too, be
readable by non-programmers, we're all going to be in a lot of
trouble. If your client is asking what is happening in a given
scenario or why, then that is a sign that the scenario is missing some
information that it doesn't currently include. This can change between
clients. Some clients might insist the value is in the minute
interactions, and perhaps it is. Others might be fine with higher
level stuff. Still others might want a mix. It's up to you to figure
out. Having said that, Cucumber should still have opinions, in my
opinion, about the best way to make it easy to strike that balance.
This brings me to DRY, and helper methods. I think many people believe
that a step definition has the same responsibilities and attributes as
a method or function; that it is "a method with a weird name". This is
a mistake. Step defs have one major responsibility: to map the
language of your domain to your language of implementation. This does
not and can not happen anywhere else. (Currently, at least.) The
responsibility of methods (or functions, or whatever), on the other
hand, is to group conceptually related blocks of code. This is a
subtle but crucial difference--I think the one that trips people up.
It is possible, of course, to include code in your step defs that
manipulates your application, but that is an implementation detail
that makes it easy to get started. It is not *why* step defs exist.
This is why having a step def call a helper method is DRY. DRY isn't
about mechanical duplication of bytes, it is about duplication of
concepts and responsibilities. Step defs and helper methods have two
distinct responsibilities and embody two different concepts, which is
why using both isn't a violation of the DRY principle.
To repeat: steps aren't methods. They are mappers. They're *almost*
named functions, and this is what causes confusion, but Cucumber isn't
nearly close enough to proving Greenspun's 10th Rule [0] to start
treating step definitions as first-class functions in their own right.

Mike, I don't think I understand the point you're trying to make.
Gherkin is just the Given/When/Then/And/But, is it not? Or that, plus
the ability to call a step that matches via a regular expression. Why
should a user who has become comfortable with the steps created via
regular expressions have to drop down to the reading implementing
computer language just to understand something like the name of a field
has changed and the underlying step definition can't find a place for
the specified input?

I fear that cucumber is quickly becoming something that doesn't fulfill
the use I had for it. It seems to be headed toward the programmer
toolspace, rather than also being accessible to testers and business
analysts.

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

[Mike Sassak]

On Fri, Nov 19, 2010 at 5:30 PM, George Dinwiddie

Post by George Dinwiddie
Alas, poor Cucumber, I knew him well.

While I might argue that writing steps in one way is a bad idea, I
think a well-written patch to Cucumber that implements the ideas
people are talking about (printing out the nested step defs) would be
a fine edition to the tool. But no one who wants that to happen has,
so far as I know, submitted a patch for it.

Post by George Dinwiddie

Post by Mike Sassak

Post by Eric Pierce

Post by Matt Wynne
There's been quite a bit of discussion about this before. A lot of us feel
that nesting steps like this is a bit of an anti-pattern.

Now that I've done some more sifting through the archives, I see that
this topic has come up in the past, and that there are conflicting
opinions about whether step-nesting is even a good idea in the first
place. One common answer is to use helper methods added to World, but
I can't shake the feeling that this doesn't address the problem. When
someone asks "How can I make nested steps better?" the reply is often
"Don't use nested steps."

Post by Matt Wynne
Question to the group: What benefits do you see in invoking steps over
invoking methods?

I think the clear advantage of steps is their readability by non-
programmers. To me, step definitions are basically general-purpose
functions that happen to have a more readable and natural-language
invocation syntax. As a programmer, of course I would prefer writing
 login("alice", "1234")
 When %{I login as "alice" with password "1234"}
But the latter form can go straight into a .feature file, while the
 When /^I login as "(.+)" with password "(.+)"$/ do |username,
password|
   login(username, password)
 end
Then shunt the "login" helper method to some other place, but that
doesn't seem very DRY, and it's quite possible that I want my "login"
method to itself be built from pre-existing steps, such as the ones
 When %{I fill in "Username" with "#{username}"}
 And %{I fill in "Password" with "#{password}"}
 And %{I press "Login"}
My thinking is that steps should be kept Gherkin-ized to as low a
 - Readable by all parties
 - I can build high-level step definitions out of low-level steps
 - I can build features using low-level OR high-level steps
Where this breaks down (at least with the current architecture) is
that when I put high-level steps in my .feature, a lot of the low-
level stuff becomes opaque. This is one of the objections often raised
against nested steps in general--that they are harder to understand
and debug. This is my objection too; I would like them to be easier to
understand and debug, and I think a "macro" concept would help here.

I've not looked at the ramifications of a "macro" concept here, but I agree
with the rest for readability, and ease of use by people who don't consider
themselves programmers (and some programmers, too).

Post by Mike Sassak

Post by Eric Pierce
What I have in mind could be implemented through some kind of pre-
processing of the .feature file. If I have step definitions that
consist purely of other steps (as I often do), I would like the option
 Given ABC
 Then DEF
those macros would get expanded to the full low-level steps before
being evaluated. I think this would greatly mitigate the "hard to
understand" and "difficult to debug" issues, while still making it
possible to write DRYer features.

I suspect that it would be possible to maintain the text of the lower level
sub-steps without a macro concept, but I've not looked at the current
cucumber implementation.  The readability of nested steps seems to be the
one place where Fitnesse/Slim surpasses Cucumber, IMO.

Post by Mike Sassak
I disagree. The advantage of *Gherkin* is that it is readable by
non-programmers. The implementation language is the implementation
language, and if it is constrained by requirements that it, too, be
readable by non-programmers, we're all going to be in a lot of
trouble. If your client is asking what is happening in a given
scenario or why, then that is a sign that the scenario is missing some
information that it doesn't currently include. This can change between
clients. Some clients might insist the value is in the minute
interactions, and perhaps it is. Others might be fine with higher
level stuff. Still others might want a mix. It's up to you to figure
out. Having said that, Cucumber should still have opinions, in my
opinion, about the best way to make it easy to strike that balance.
This brings me to DRY, and helper methods. I think many people believe
that a step definition has the same responsibilities and attributes as
a method or function; that it is "a method with a weird name". This is
a mistake. Step defs have one major responsibility: to map the
language of your domain to your language of implementation. This does
not and can not happen anywhere else. (Currently, at least.) The
responsibility of methods (or functions, or whatever), on the other
hand, is to group conceptually related blocks of code. This is a
subtle but crucial difference--I think the one that trips people up.
It is possible, of course, to include code in your step defs that
manipulates your application, but that is an implementation detail
that makes it easy to get started. It is not *why* step defs exist.
This is why having a step def call a helper method is DRY. DRY isn't
about mechanical duplication of bytes, it is about duplication of
concepts and responsibilities. Step defs and helper methods have two
distinct responsibilities and embody two different concepts, which is
why using both isn't a violation of the DRY principle.
To repeat: steps aren't methods. They are mappers. They're *almost*
named functions, and this is what causes confusion, but Cucumber isn't
nearly close enough to proving Greenspun's 10th Rule [0] to start
treating step definitions as first-class functions in their own right.

Mike, I don't think I understand the point you're trying to make. Gherkin is
just the Given/When/Then/And/But, is it not?  Or that, plus the ability to
call a step that matches via a regular expression.  Why should a user who
has become comfortable with the steps created via regular expressions have
to drop down to the reading implementing computer language just to
understand something like the name of a field has changed and the underlying
step definition can't find a place for the specified input?

They don't need to. There's nothing that prevents anyone from writing
purely imperative scenarios using the fine-grained steps that ship
with one library or another, (or using a library of them created by a
developer) but the second you start making your own steps--including
nesting them--you're not writing Gherkin, you're writing Ruby, and I'm
of the opinion that that means you should start actually writing Ruby
(and learning a bit about it if need be) rather than acting like
you're not. Trying to hide the fact from people that they're dealing
with a full-blown programming language is, in my opinion, a losing
proposition.

Post by George Dinwiddie
I fear that cucumber is quickly becoming something that doesn't fulfill the
use I had for it.  It seems to be headed toward the programmer toolspace,
rather than also being accessible to testers and business analysts.

I think there are two camps here. One is the camp that sees the
features as belonging to the customer (or the testers or BAs,
what-have-you), and the step defs as belonging to the devs, while the
other camp sees both belonging primarily to the testers. I very
obviously fall in the former camp. There's no reason I can think of
that Cucumber can't support both workflows (even if I think the other
camp is wrong), but, again, no one in the BAs all the way down camp is
submitting any patches to support their preferred style of workflow.

Mike

Post by George Dinwiddie
 - George
--
 ----------------------------------------------------------------------
 * George Dinwiddie *                      http://blog.gdinwiddie.com
 Software Development                    http://www.idiacomputing.com
 Consultant and Coach                    http://www.agilemaryland.org
 ----------------------------------------------------------------------
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[George Dinwiddie]

Mike

Post by Mike Sassak
On Fri, Nov 19, 2010 at 5:30 PM, George Dinwiddie

Post by George Dinwiddie
Alas, poor Cucumber, I knew him well.

While I might argue that writing steps in one way is a bad idea, I
think a well-written patch to Cucumber that implements the ideas
people are talking about (printing out the nested step defs) would be
a fine edition to the tool. But no one who wants that to happen has,
so far as I know, submitted a patch for it.

For my part, I've been too busy to even document the way of working and
the issue, much less to dig into the code. My examples of cucumber are
a little out of date at the moment.

- George
--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Eric Pierce]

Post by Mike Sassak
I think there are two camps here. One is the camp that sees the
features as belonging to the customer (or the testers or BAs,
what-have-you), and the step defs as belonging to the devs, while the
other camp sees both belonging primarily to the testers.

I don't know that I'm in one camp or the other--the idealist in me
wishes that BAs or domain specialists were more involved in scenario
development, and that developers were more involved in the coding &
step definition, but my experience with Cucumber thus far has been
mainly in the role of tester. As a tester, in order to avoid repeating
many small mundane steps, I want the ability to build higher-level
steps from lower-level ones. True, the 'steps' method already gives me
a way to do that; what I wish for is more transparency into those
inner steps.

Post by Mike Sassak
While I might argue that writing steps in one way is a bad idea, I
think a well-written patch to Cucumber that implements the ideas
people are talking about (printing out the nested step defs) would be
a fine edition to the tool. But no one who wants that to happen has,
so far as I know, submitted a patch for it.

Agreed, talk is cheap. I think I got the answer I needed from this
thread--that yes this topic has come up before, and yes others have
expressed interest in such a feature (even if there is disagreement
about the need for it). I don't expect Cucumber to be all things to
all people, but it's within my abilities to nudge it a little closer
to what I want it to be. I'll work on a patch.

[George Dinwiddie]

Eric,

Post by Eric Pierce

Post by Mike Sassak
I think there are two camps here. One is the camp that sees the
features as belonging to the customer (or the testers or BAs,
what-have-you), and the step defs as belonging to the devs, while the
other camp sees both belonging primarily to the testers.

I don't know that I'm in one camp or the other--the idealist in me
wishes that BAs or domain specialists were more involved in scenario
development, and that developers were more involved in the coding&
step definition, but my experience with Cucumber thus far has been
mainly in the role of tester. As a tester, in order to avoid repeating
many small mundane steps, I want the ability to build higher-level
steps from lower-level ones. True, the 'steps' method already gives me
a way to do that; what I wish for is more transparency into those
inner steps.

Post by Mike Sassak
While I might argue that writing steps in one way is a bad idea, I
think a well-written patch to Cucumber that implements the ideas
people are talking about (printing out the nested step defs) would be
a fine edition to the tool. But no one who wants that to happen has,
so far as I know, submitted a patch for it.

Agreed, talk is cheap. I think I got the answer I needed from this
thread--that yes this topic has come up before, and yes others have
expressed interest in such a feature (even if there is disagreement
about the need for it). I don't expect Cucumber to be all things to
all people, but it's within my abilities to nudge it a little closer
to what I want it to be. I'll work on a patch.

If you reach mid-December and haven't created that patch, but want some
help looking at it, then please contact me. I won't have time before then.

- George
--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Eric Pierce]

Post by George Dinwiddie
If you reach mid-December and haven't created that patch, but want some
help looking at it, then please contact me.  I won't have time before then.

Thanks, George. I'm pretty determined to tackle this, but if I get
stuck, I will keep you in mind.

[Aslak Hellesøy]

Post by Eric Pierce

Post by George Dinwiddie
If you reach mid-December and haven't created that patch, but want some
help looking at it, then please contact me. I won't have time before then.

Thanks, George. I'm pretty determined to tackle this, but if I get
stuck, I will keep you in mind.

During my recent work to implement a pure java cucumber I have
(almost) come up with the long sought new internal model and API for
the next major version.

I recommend you wait until that is ported back to the ruby code.

Aslak

Post by Eric Pierce
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

[Eric Pierce]

Post by Aslak Hellesøy
During my recent work to implement a pure java cucumber I have
(almost) come up with the long sought new internal model and API for
the next major version.
I recommend you wait until that is ported back to the ruby code.

OK, I will hold off for now.

[Rob Park]

I've seen this a lot lately with my current team. I agree that there
are some anti-patterns in its over-use, however, it is keeping our
scenarios much more readable and focused on the goal of the scenario.

Methods instead of steps would actually be better on the one hand,
because /the biggest problem I have with macro-steps is the missing
critical link of the stack on failure/, being which step in the macro
step failed.

I do think that macro-steps are easier to follow (especially for
others I work with). And I like to create macro-steps by extracting
from other passing scenarios. (E.g. navigation scenario about who and
how to get to a page; followed by a series of scenarios for the
functions on that page using a macro navigation step to get there.) I
agree, not very DRY, but still my preference is to have the same steps
in 2 places (at least in the same form) rather than a translation to
their underlying functions (so as not to lose their original intent).

//rob

Post by aslak hellesoy

Post by Matt Wynne
cheers,
Matt
07974 430184

Post by Eric Pierce
I really dig Cucumber's support for building complex steps out of
simpler ones, but sometimes I wish there was an option to "expand"
those inner steps when they are executed, especially those times when
I have a bug in an inner step--the backtrace can be pretty useless.
What I would like to see is either a command-line option, or something
similar to the 'steps' method (maybe 'macro'?) with a multiline
Given ABC
Then DEF
Given /^ABC$/ do
  macro %Q{
    Given A
      And B
      And C
  }
end
Then /^DEF$/ do
  macro %Q{
    Then D
      And E
      And F
  }
end
  Given A
    And B
    And C
  Then D
    And E
    And F
  Given ABC
    Given A
      And B
      And C
  Then DEF
    Then D
      And E
      And F
In other words, the ABC and DEF steps are just stand-ins for the fully-
expanded inner steps. Nearly identical to the 'steps' syntax, but
evaluated as if the inner steps had been explicitly included in
the .feature file.
The topic of macros was touched upon in an older thread ("Mixing ruby
code and steps %Q{ } in a step definition?") but I have not seen
mention of expanding the steps in the output as I've described above.
I've started poking through the Cucumber code and thinking of ways to
implement this, but I am wondering if anyone else has interest in such
a feature, and also whether it has been discussed or attempted before.
Thoughts?

Andrew, are you going to hold up your sign? ;)
There's been quite a bit of discussion about this before. A lot of us feel
that nesting steps like this is a bit of an anti-pattern.

Whenever I feel the temptation to use a step Given /something super useful/
in another stepdef I extract the body of Given /something super useful/ to a
CukeHelpers#something_super_useful module method.
Then I World(CukeHelpers)
Now I can invoke a plain old method from my stepdef instead of invoking a
step
Question to the group: What benefits do you see in invoking steps over
invoking methods?
Aslak
Search the group for posts by Andrew Premdas and you'll get the picture.

Post by Matt Wynne
This isn't obviously a great reason, but I also suspect this would be
pretty awkward to build, and right now the internals of Cucumber are
gradually being cleaned up. Until that's done it's hard for us to really
even think about building this kind of thing.
cheers,
Matt
http://blog.mattwynne.net
--
You received this message because you are subscribed to the Google Groups
"Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[byrnejb]

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps over
invoking methods?

Expediency.

[aslak hellesoy]

Post by byrnejb

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps over
invoking methods?

Expediency.

I have heard "expediency" used as an argument for copying and pasting code
too, and this sounds a little similar.

Post by byrnejb
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[George Dinwiddie]

Post by byrnejb

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps

over

Post by aslak hellesoy
invoking methods?

Expediency.
I have heard "expediency" used as an argument for copying and pasting
code too, and this sounds a little similar.

For me, it "communication."
--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[aslak hellesoy]

On Mon, Nov 22, 2010 at 6:15 PM, George Dinwiddie

Post by George Dinwiddie

Post by byrnejb

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps

over

Post by aslak hellesoy
invoking methods?

Expediency.
I have heard "expediency" used as an argument for copying and pasting
code too, and this sounds a little similar.

For me, it "communication."

Are you saying that nested steps helps achieve better communication? -And
more so if the nestedness is displayed in the output?

Aslak

Post by George Dinwiddie
--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[George Dinwiddie]

Post by aslak hellesoy
On Mon, Nov 22, 2010 at 6:15 PM, George Dinwiddie

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps

over

Post by aslak hellesoy
invoking methods?

Expediency.
I have heard "expediency" used as an argument for copying and pasting
code too, and this sounds a little similar.
For me, it "communication."
Are you saying that nested steps helps achieve better communication?
-And more so if the nestedness is displayed in the output?

Nested steps show the decomposition of higher level steps into more
primitive ones. This helps communicate with different people, and helps
some people understand the higher level constructs from the more
concrete building blocks.

The /optional/ display of the nestedness in the output is helpful for
communication, particularly when a test fails.

- George
--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Matt Wynne]

Post by aslak hellesoy
On Mon, Nov 22, 2010 at 6:15 PM, George Dinwiddie

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps

over

Post by aslak hellesoy
invoking methods?

Expediency.
I have heard "expediency" used as an argument for copying and pasting
code too, and this sounds a little similar.
For me, it "communication."
Are you saying that nested steps helps achieve better communication?
-And more so if the nestedness is displayed in the output?

Nested steps show the decomposition of higher level steps into more primitive ones. This helps communicate with different people, and helps some people understand the higher level constructs from the more concrete building blocks.
The /optional/ display of the nestedness in the output is helpful for communication, particularly when a test fails.
- George

I really value your perspective and contribution to this conversation George. I feel like as long as Cucumber supports nested steps, I think it should be possible to show the nesting in the output. However I am starting to think that we've made a mistake in supporting this feature at all, because it's encouraging people to write what is ultimately, harder-to-maintain code. As Dale Emery says: test automation *is* software development. Step Definitions are not methods, and Cucumber is never going to be as good as Ruby at managing and debugging call stacks. The idea of letting people who don't feel comfortable readying and writing Ruby methods loose in the step definition layer worries me - I'd prefer to see them pairing with developers who are confident enough to keep the code as lean as possible.

In code, we talk about the refactoring operation "inline method" where the method doesn't do anything other than call another method. I think we need to start encouraging people to "inline step definition" so that these macro steps contain less indirection and complexity. Obviously what you trade off here is the maintainability of the codebase vs the readability and trust with less technical members of the team. I guess it's up to each of us to find our own balance point.

cheers,
Matt

matt-***@public.gmane.org
07974 430184

[George Dinwiddie]

Matt,

Post by Matt Wynne
I really value your perspective and contribution to this conversation
George. I feel like as long as Cucumber supports nested steps, I
think it should be possible to show the nesting in the output.
However I am starting to think that we've made a mistake in
supporting this feature at all, because it's encouraging people to
write what is ultimately, harder-to-maintain code.

Harder to maintain by whom?

Post by Matt Wynne
As Dale Emery
says: test automation *is* software development. Step Definitions are
not methods, and Cucumber is never going to be as good as Ruby at
managing and debugging call stacks.

Ask Dale, but I don't think he's suggesting we should drop back to
programming languages. Step definitions /are/ programming, but they're
in the language of the business and of the abstractions the business
understands.

Post by Matt Wynne
The idea of letting people who
don't feel comfortable readying and writing Ruby methods loose in the
step definition layer worries me - I'd prefer to see them pairing
with developers who are confident enough to keep the code as lean as
possible.

If I'm going to abandon the aspect of readability for the business, then
why should I use cucumber at all? I can as easily write acceptance
tests in rspec.

Post by Matt Wynne
In code, we talk about the refactoring operation "inline method"
where the method doesn't do anything other than call another method.
I think we need to start encouraging people to "inline step
definition" so that these macro steps contain less indirection and
complexity. Obviously what you trade off here is the maintainability
of the codebase vs the readability and trust with less technical
members of the team. I guess it's up to each of us to find our own
balance point.

In the past year, I've seen cucumber look more like code and be more
tuned to programmers. I think this is at the expense of the business
stakeholders and the testers. I also think it's at the expense of
cucumber, as I think it's abandoning the niche where it's most valuable.
As a programmer, I don't need a natural-language focused test runner.

- George
--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Andrew Premdas]

Post by George Dinwiddie
Matt,

Post by Matt Wynne
I really value your perspective and contribution to this conversation
George. I feel like as long as Cucumber supports nested steps, I
think it should be possible to show the nesting in the output.
However I am starting to think that we've made a mistake in
supporting this feature at all, because it's encouraging people to
write what is ultimately, harder-to-maintain code.

Harder to maintain by whom?
By anyone who is using/writing step definitions
As Dale Emery

Post by Matt Wynne
says: test automation *is* software development. Step Definitions are
not methods, and Cucumber is never going to be as good as Ruby at
managing and debugging call stacks.

Ask Dale, but I don't think he's suggesting we should drop back to
programming languages. Step definitions /are/ programming, but they're in
the language of the business and of the abstractions the business
understands.
Step definitions are in programming languages, it is after all a ruby (or

java, javascript, php ...) file. And there are some lovely DSL's around to
make this very simple and readable.

Post by George Dinwiddie
The idea of letting people who

Post by Matt Wynne
don't feel comfortable readying and writing Ruby methods loose in the
step definition layer worries me - I'd prefer to see them pairing
with developers who are confident enough to keep the code as lean as
possible.

If I'm going to abandon the aspect of readability for the business, then
why should I use cucumber at all? I can as easily write acceptance tests in
rspec.
You're not abandoning that, its the features that are read by the business.

By focusing on the readability of the features you are enhancing the
communication between the business and the developers and ensuring that the
business gets what they want in a language they can read and understand.

In code, we talk about the refactoring operation "inline method"

Post by George Dinwiddie

Post by Matt Wynne
where the method doesn't do anything other than call another method.
I think we need to start encouraging people to "inline step
definition" so that these macro steps contain less indirection and
complexity. Obviously what you trade off here is the maintainability
of the codebase vs the readability and trust with less technical
members of the team. I guess it's up to each of us to find our own
balance point.

In the past year, I've seen cucumber look more like code and be more tuned
to programmers. I think this is at the expense of the business stakeholders
and the testers. I also think it's at the expense of cucumber, as I think
it's abandoning the niche where it's most valuable. As a programmer, I
don't need a natural-language focused test runner.

The mechanisms used to replace nested steps originate from Ben Mabey's
article on writing declarative features rather than imperative ones from
about 2-3 years ago. These sort of features are much more focused at the
business and look much less like code. This is not about cucumber looking
like code, as cucumber is two things, features and step definitions. Only
the step definitions are looking more like code, and that code is far more
readable, easier to debug and easier to maintain. This approach allows
features are closer to natural language, with less tables, less complex
matching mechanisms and less restrictions on language. It also reduces the
cost of creating new step definitions, as if you follow this approach you
quickly end up with a useful library that can act like a domain specific
testing dsl for your applications step definitions. This makes implementing
new step definitions much easier.

Andrew
- George

Post by George Dinwiddie
--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[George Dinwiddie]

Andrew,

OK, I give up. I don't think you're acknowledging my point that the
business needs to have an understanding that often goes deeper than the
feature description.

I will say that if cucumber becomes just another programmer oriented
tool, I will likely abandon it as I don't think it will meet the needs
that I perceive for my clients.

- George

Post by Matt Wynne
Matt,
I really value your perspective and contribution to this conversation
George. I feel like as long as Cucumber supports nested steps, I
think it should be possible to show the nesting in the output.
However I am starting to think that we've made a mistake in
supporting this feature at all, because it's encouraging people to
write what is ultimately, harder-to-maintain code.
Harder to maintain by whom?
By anyone who is using/writing step definitions
As Dale Emery
says: test automation *is* software development. Step
Definitions are
not methods, and Cucumber is never going to be as good as Ruby at
managing and debugging call stacks.
Ask Dale, but I don't think he's suggesting we should drop back to
programming languages. Step definitions /are/ programming, but
they're in the language of the business and of the abstractions the
business understands.
Step definitions are in programming languages, it is after all a ruby
(or java, javascript, php ...) file. And there are some lovely DSL's
around to make this very simple and readable.
The idea of letting people who
don't feel comfortable readying and writing Ruby methods loose in the
step definition layer worries me - I'd prefer to see them pairing
with developers who are confident enough to keep the code as lean as
possible.
If I'm going to abandon the aspect of readability for the business,
then why should I use cucumber at all? I can as easily write
acceptance tests in rspec.
You're not abandoning that, its the features that are read by the
business. By focusing on the readability of the features you are
enhancing the communication between the business and the developers and
ensuring that the business gets what they want in a language they can
read and understand.
In code, we talk about the refactoring operation "inline method"
where the method doesn't do anything other than call another method.
I think we need to start encouraging people to "inline step
definition" so that these macro steps contain less indirection and
complexity. Obviously what you trade off here is the maintainability
of the codebase vs the readability and trust with less technical
members of the team. I guess it's up to each of us to find our own
balance point.
In the past year, I've seen cucumber look more like code and be more
tuned to programmers. I think this is at the expense of the
business stakeholders and the testers. I also think it's at the
expense of cucumber, as I think it's abandoning the niche where it's
most valuable. As a programmer, I don't need a natural-language
focused test runner.
The mechanisms used to replace nested steps originate from Ben Mabey's
article on writing declarative features rather than imperative ones from
about 2-3 years ago. These sort of features are much more focused at the
business and look much less like code. This is not about cucumber
looking like code, as cucumber is two things, features and step
definitions. Only the step definitions are looking more like code, and
that code is far more readable, easier to debug and easier to maintain.
This approach allows features are closer to natural language, with less
tables, less complex matching mechanisms and less restrictions on
language. It also reduces the cost of creating new step definitions, as
if you follow this approach you quickly end up with a useful library
that can act like a domain specific testing dsl for your applications
step definitions. This makes implementing new step definitions much easier.

--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[aslak hellesoy]

On Thu, Nov 25, 2010 at 4:00 PM, George Dinwiddie

Post by Matt Wynne
Andrew,
OK, I give up. I don't think you're acknowledging my point that the
business needs to have an understanding that often goes deeper than the
feature description.
I will say that if cucumber becomes just another programmer oriented tool,
I will likely abandon it as I don't think it will meet the needs that I
perceive for my clients.

Let me end this discussion by saying that I'll do my best to add support for
outputting nested steps in the next major version:

Feature: Blogging
Scenario: Post an entry
Given I am logged in
When I go to "/login"
And I enter "topsecretuser" for "User"
And I click "Login"
When I enter a blog post
When I go to "/posts"
And I enter "Boyakasha" for "Title"
And I enter "In da house" for "Body"
And I click "Publish!"
Then it should be published
When I go to "/posts/oyakasha"
Then I should see "Boyakasha"

(And this would work at arbitrary levels of nesting)

It's a technique I will not use my self
It's a technique I will warn against in the documentation
It's just a long rope you can do whatever you want with
I understand that some people will want it and others will shun it. That's
fine with me.

There will be a command line switch to turn it on: --expand-steps

Mmmkay?

Aslak

- George

Post by Matt Wynne

Post by Matt Wynne
Matt,
I really value your perspective and contribution to this conversation
George. I feel like as long as Cucumber supports nested steps, I
think it should be possible to show the nesting in the output.
However I am starting to think that we've made a mistake in
supporting this feature at all, because it's encouraging people to
write what is ultimately, harder-to-maintain code.
Harder to maintain by whom?
By anyone who is using/writing step definitions
As Dale Emery
says: test automation *is* software development. Step
Definitions are
not methods, and Cucumber is never going to be as good as Ruby at
managing and debugging call stacks.
Ask Dale, but I don't think he's suggesting we should drop back to
programming languages. Step definitions /are/ programming, but
they're in the language of the business and of the abstractions the
business understands.
Step definitions are in programming languages, it is after all a ruby
(or java, javascript, php ...) file. And there are some lovely DSL's
around to make this very simple and readable.
The idea of letting people who
don't feel comfortable readying and writing Ruby methods loose in the
step definition layer worries me - I'd prefer to see them pairing
with developers who are confident enough to keep the code as lean as
possible.
If I'm going to abandon the aspect of readability for the business,
then why should I use cucumber at all? I can as easily write
acceptance tests in rspec.
You're not abandoning that, its the features that are read by the
business. By focusing on the readability of the features you are
enhancing the communication between the business and the developers and
ensuring that the business gets what they want in a language they can
read and understand.
In code, we talk about the refactoring operation "inline method"
where the method doesn't do anything other than call another method.
I think we need to start encouraging people to "inline step
definition" so that these macro steps contain less indirection and
complexity. Obviously what you trade off here is the
maintainability
of the codebase vs the readability and trust with less technical
members of the team. I guess it's up to each of us to find our own
balance point.
In the past year, I've seen cucumber look more like code and be more
tuned to programmers. I think this is at the expense of the
business stakeholders and the testers. I also think it's at the
expense of cucumber, as I think it's abandoning the niche where it's
most valuable. As a programmer, I don't need a natural-language
focused test runner.
The mechanisms used to replace nested steps originate from Ben Mabey's
article on writing declarative features rather than imperative ones from
about 2-3 years ago. These sort of features are much more focused at the
business and look much less like code. This is not about cucumber
looking like code, as cucumber is two things, features and step
definitions. Only the step definitions are looking more like code, and
that code is far more readable, easier to debug and easier to maintain.
This approach allows features are closer to natural language, with less
tables, less complex matching mechanisms and less restrictions on
language. It also reduces the cost of creating new step definitions, as
if you follow this approach you quickly end up with a useful library
that can act like a domain specific testing dsl for your applications
step definitions. This makes implementing new step definitions much easier.

--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[Eric Pierce]

Post by aslak hellesoy
There will be a command line switch to turn it on: --expand-steps
Mmmkay?

Thanks Aslak! I had no idea this subject was such a barrel of worms...
But the discussion here has indeed prompted me to rethink the way I've
been implementing step definitions. I appreciate everyone's comments
and perspectives.

[George Dinwiddie]

Thanks, Aslak,

Post by aslak hellesoy
(And this would work at arbitrary levels of nesting)
It's a technique I will not use my self
It's a technique I will warn against in the documentation
It's just a long rope you can do whatever you want with
I understand that some people will want it and others will shun it.
That's fine with me.
There will be a command line switch to turn it on: --expand-steps
Mmmkay?

We'll see when we get to play with it. I'm hoping to develop some
examples that illustrate the method of working that I've seen be useful.

- George
--
Dec. 14 - Agile Richmond in Glen Allen, VA
http://georgedinwiddie.eventbrite.com/
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

[Rob Park]

+1

--
Rob
--
http://twitter.com/robpark
http://leandog.com

Post by George Dinwiddie

Post by aslak hellesoy
On Mon, Nov 22, 2010 at 6:15 PM, George Dinwiddie
         > Question to the group: What benefits do you see in invoking steps
            over
         > invoking methods?
            Expediency.
        I have heard "expediency" used as an argument for copying and
        pasting
        code too, and this sounds a little similar.
    For me, it "communication."
Are you saying that nested steps helps achieve better communication?
-And more so if the nestedness is displayed in the output?

Nested steps show the decomposition of higher level steps into more
primitive ones.  This helps communicate with different people, and helps
some people understand the higher level constructs from the more
concrete building blocks.
The /optional/ display of the nestedness in the output is helpful for
communication, particularly when a test fails.
  - George
--
  Dec. 14 - Agile Richmond in Glen Allen, VA
 http://georgedinwiddie.eventbrite.com/
  ----------------------------------------------------------------------
   * George Dinwiddie *                      http://blog.gdinwiddie.com
   Software Development                    http://www.idiacomputing.com
   Consultant and Coach                    http://www.agilemaryland.org
  ----------------------------------------------------------------------

[Franklin Webber]

I use nested steps. Though, I often don't have the need for the sub-
steps to appear in the output.

I have found that I often create a step that collects several
variations of different steps. The collector step will usually
implements a table and can be called directly.

The benefit of having this collector step is that my steps are more
clear, as their are step definitions tailored to each variation, while
the code remains DRY.

* Any operations common to the family of steps
** Validation of the object
** Defaults can be applied to all sub-steps
** Common operations within all steps

A trivial example: https://gist.github.com/710405

Post by aslak hellesoy

Post by byrnejb

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps over
invoking methods?

Expediency.

I have heard "expediency" used as an argument for copying and pasting code
too, and this sounds a little similar.

Post by byrnejb
 --
You received this message because you are subscribed to the Google Groups
"Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[Matt Wynne]

Post by Franklin Webber
I use nested steps. Though, I often don't have the need for the sub-
steps to appear in the output.
I have found that I often create a step that collects several
variations of different steps. The collector step will usually
implements a table and can be called directly.
The benefit of having this collector step is that my steps are more
clear, as their are step definitions tailored to each variation, while
the code remains DRY.
* Any operations common to the family of steps
** Validation of the object
** Defaults can be applied to all sub-steps
** Common operations within all steps
A trivial example: https://gist.github.com/710405

What I don't understand in this example, is why you see it to be an advantage to implement the re-usable behaviour in a step, rather than a method?

Surely it would be just as clear, and I think, more maintainable, to extract a helper method called #create_events and have all three step definitions call that?

Here's my refactoring of your example:

https://gist.github.com/gists/711496

Post by Franklin Webber

Post by aslak hellesoy

Post by byrnejb

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps over
invoking methods?

Expediency.

I have heard "expediency" used as an argument for copying and pasting code
too, and this sounds a little similar.

Post by byrnejb
--
You received this message because you are subscribed to the Google Groups
"Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

--
You received this message because you are subscribed to the Google Groups "Cukes" group.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

cheers,
Matt

matt-***@public.gmane.org
07974 430184

[Franklin Webber]

Thanks Matt. I simply failed to finished my refactor. Looks great.
Alright, down with NESTED STEPS!

Post by Matt Wynne

I use nested steps.  Though, I often don't have the need for the sub-
steps to appear in the output.
I have found that I often create a step that collects several
variations of different steps.  The collector step will usually
implements a table and can be called directly.
The benefit of having this collector step is that my steps are more
clear, as their are step definitions tailored to each variation, while
the code remains DRY.
* Any operations common to the family of steps
** Validation of the object
** Defaults can be applied to all sub-steps
** Common operations within all steps
A trivial example:https://gist.github.com/710405

What I don't understand in this example, is why you see it to be an advantage to implement the re-usable behaviour in a step, rather than a method?
Surely it would be just as clear, and I think, more maintainable, to extract a helper method called #create_events and have all three step definitions call that?
https://gist.github.com/gists/711496

Post by aslak hellesoy

Post by byrnejb

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps over
invoking methods?

Expediency.

I have heard "expediency" used as an argument for copying and pasting code
too, and this sounds a little similar.

Post by byrnejb
 --
You received this message because you are subscribed to the Google Groups
"Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

--
You received this message because you are subscribed to the Google Groups "Cukes" group.
For more options, visit this group athttp://groups.google.com/group/cukes?hl=en.

cheers,
Matt
07974 430184

[byrnejb]

Post by aslak hellesoy

Post by byrnejb

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps over
invoking methods?

Expediency.

I have heard "expediency" used as an argument for copying and pasting code
too, and this sounds a little similar.>  --

I never said that it was a GOOD reason. . .


On the other hand, I think it worthwhile to reflect on how a newcomer
to the Ruby/Rails/BDD environment feels. Once one has achieved a
degree of competency with these tools then much of what is recommended
finally makes sense. But for someone overwhelmed by many things at
once, all of which are unfamiliar, most of it has no meaning and in
such circumstance there is a place for reusing the little one knows
and feels secure with.

Once one understands how to write steps then the natural extension of
that is to nest them. This in itself should not be condemned out of
hand but rather viewed as progression along the path of knowledge.
After all, whom of us can look at all the code that we wrote not so
long ago and fail to cringe at some things which we once thought
superlative? it takes time to master new things and small increments
of learning are surer than giant leaps of faith.

[Andrew Premdas]

Post by byrnejb

Post by aslak hellesoy

Post by byrnejb

Post by aslak hellesoy
Question to the group: What benefits do you see in invoking steps

over

Post by aslak hellesoy

Post by byrnejb

Post by aslak hellesoy
invoking methods?

Expediency.

I have heard "expediency" used as an argument for copying and pasting

code

Post by aslak hellesoy
too, and this sounds a little similar.> --

I never said that it was a GOOD reason. . .
On the other hand, I think it worthwhile to reflect on how a newcomer
to the Ruby/Rails/BDD environment feels. Once one has achieved a
degree of competency with these tools then much of what is recommended
finally makes sense. But for someone overwhelmed by many things at
once, all of which are unfamiliar, most of it has no meaning and in
such circumstance there is a place for reusing the little one knows
and feels secure with.
Once one understands how to write steps then the natural extension of
that is to nest them. This in itself should not be condemned out of
hand but rather viewed as progression along the path of knowledge.
After all, whom of us can look at all the code that we wrote not so
long ago and fail to cringe at some things which we once thought
superlative? it takes time to master new things and small increments
of learning are surer than giant leaps of faith.

The only reason for all my posts about nested steps is to pass on my
experience of nested steps, so people can get past them ASAP, and progress
to writing better steps and better features. Investing in nested steps and
then moving to helper methods is a painful experience (especially if you
wrote as many nested steps as we did). Far better to use the knowledge in
this group, to skip them entirely, and invest the saved effort in learning
the DSL for driving steps, and the techniques for using helper methods. The
aim of all the posts against nested steps is to help other cucumber users.

Andrew



You received this message because you are subscribed to the Google Groups

Post by byrnejb
"Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[byrnejb]

Post by Andrew Premdas
The only reason for all my posts about nested steps is to pass on my
experience of nested steps, so people can get past them ASAP, and progress
to writing better steps and better features. Investing in nested steps and
then moving to helper methods is a painful experience (especially if you
wrote as many nested steps as we did). Far better to use the knowledge in
this group, to skip them entirely, and invest the saved effort in learning
the DSL for driving steps, and the techniques for using helper methods. The
aim of all the posts against nested steps is to help other cucumber users.

I never thought otherwise. And I also share your opinion respecting
nested steps.

Nonetheless, I do have a lot of these kicking about from the days when
I knew even less than I know now. And I still recall just how
difficult it was to understand things even with a great deal of
informed advice given to me on this list. Some things that one is
told just do not seem to make much sense until you experience them for
yourself. Only then does the light-bulb goes on.

It does not help that the libraries of steps_definitions distributed
with Cucumber-Rails, Webrat and so forth encourage both step nesting
( reuse ) and imperative feature statements ( When /^I fill in "(.*)"
with "(.*)"$/ do |arg1,arg2| ). These libraries are the first
introduction to step_definitions for most adopters. their appearance
and usage inevitably sets the expectation as to what is 'right'. While
their provision is well intentioned I have come to believe that their
example starts many people down the wrong path with respect to both
step definitions and feature statements.

[Matt Wynne]

Post by byrnejb

Post by Andrew Premdas
The only reason for all my posts about nested steps is to pass on my
experience of nested steps, so people can get past them ASAP, and progress
to writing better steps and better features. Investing in nested steps and
then moving to helper methods is a painful experience (especially if you
wrote as many nested steps as we did). Far better to use the knowledge in
this group, to skip them entirely, and invest the saved effort in learning
the DSL for driving steps, and the techniques for using helper methods. The
aim of all the posts against nested steps is to help other cucumber users.

I never thought otherwise. And I also share your opinion respecting
nested steps.
Nonetheless, I do have a lot of these kicking about from the days when
I knew even less than I know now. And I still recall just how
difficult it was to understand things even with a great deal of
informed advice given to me on this list. Some things that one is
told just do not seem to make much sense until you experience them for
yourself. Only then does the light-bulb goes on.
It does not help that the libraries of steps_definitions distributed
with Cucumber-Rails, Webrat and so forth encourage both step nesting
( reuse ) and imperative feature statements ( When /^I fill in "(.*)"
with "(.*)"$/ do |arg1,arg2| ). These libraries are the first
introduction to step_definitions for most adopters. their appearance
and usage inevitably sets the expectation as to what is 'right'. While
their provision is well intentioned I have come to believe that their
example starts many people down the wrong path with respect to both
step definitions and feature statements.

+1

What are we going to do about it?


cheers,
Matt

matt-***@public.gmane.org
07974 430184

[Andrew Premdas]

Post by byrnejb

Post by byrnejb

Post by Andrew Premdas
The only reason for all my posts about nested steps is to pass on my
experience of nested steps, so people can get past them ASAP, and

progress

Post by byrnejb

Post by Andrew Premdas
to writing better steps and better features. Investing in nested steps

and

Post by byrnejb

Post by Andrew Premdas
then moving to helper methods is a painful experience (especially if you
wrote as many nested steps as we did). Far better to use the knowledge

in

Post by byrnejb

Post by Andrew Premdas
this group, to skip them entirely, and invest the saved effort in

learning

Post by byrnejb

Post by Andrew Premdas
the DSL for driving steps, and the techniques for using helper methods.

The

Post by byrnejb

Post by Andrew Premdas
aim of all the posts against nested steps is to help other cucumber

users.

Post by byrnejb
I never thought otherwise. And I also share your opinion respecting
nested steps.
Nonetheless, I do have a lot of these kicking about from the days when
I knew even less than I know now. And I still recall just how
difficult it was to understand things even with a great deal of
informed advice given to me on this list. Some things that one is
told just do not seem to make much sense until you experience them for
yourself. Only then does the light-bulb goes on.
It does not help that the libraries of steps_definitions distributed
with Cucumber-Rails, Webrat and so forth encourage both step nesting
( reuse ) and imperative feature statements ( When /^I fill in "(.*)"
with "(.*)"$/ do |arg1,arg2| ). These libraries are the first
introduction to step_definitions for most adopters. their appearance
and usage inevitably sets the expectation as to what is 'right'. While
their provision is well intentioned I have come to believe that their
example starts many people down the wrong path with respect to both
step definitions and feature statements.

+1
+1
What are we going to do about it?
Unfortunately I don't think we can get rid of them. Personally I not sure I

would use a single one at the moment, and just keep them around to have
examples of using capybara to hand. But without them it would be very hard
to write your first feature, as there would be quite alot more to understand
before you get anywhere.

Perhaps blogging is the solution. Writing articles about starting Cucumber
without web steps perhaps might have a similar effect to Ben Mabey's
original declarative article, if the article is good enough and enough
people read it. And yes I am sort of volunteering, but it will take a while
to get it together :)

Andrew

Post by byrnejb
cheers,
Matt
07974 430184
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[byrnejb]

Post by Matt Wynne

Post by byrnejb
It does not help that the libraries of steps_definitions distributed
with Cucumber-Rails, Webrat and so forth encourage both step nesting
( reuse ) and imperative feature statements ( When /^I fill in "(.*)"
with "(.*)"$/ do |arg1,arg2| ).  These libraries are the first
introduction to step_definitions for most adopters.  their appearance
and usage inevitably sets the expectation as to what is 'right'. While
their provision is well intentioned I have come to believe that their
example starts many people down the wrong path with respect to both
step definitions and feature statements.

+1
What are we going to do about it?

Well, I have given this matter some thought in the past and I do not
have a good answer to that question. There may not be one. Cucumber,
by its very nature and design, expresses the tensions between design
and implementation. The two are widely separated spaces,
distinguished not only in purpose but also in concept and language.

In my ever evolving article on the Cucumber wiki ( Cucumber
Backgrounder ) I explore this tension to the best of my current
knowledge but I cannot resolve the different goals that each sets.

I have had a long and difficult road to BDD ( not that I have finished
the journey ), coming as I do from a professional background in heavy
and mid-range iron using mainly 4GLs, central data dictionaries, and
CODASYL databases. The concepts of OOP, TDD and BDD always seemed to
elude me regardless how much effort I expended trying to grasp their
essentials. I came to Ruby after spending four futile years with Java
watching the libraries grow exponentially in that time. I tried
TestUnit, then RSPec, RSpec Stories. Because of that last effort I
happened to be present on the RSpec mailing list when Cucumber was
first broached as an idea.

You can easily follow the evolution of my knowledge thereafter through
the archives of this very mailing list and that of RSpec. It is not
too much to say that for me Cucumber alone provided the entry point
into gradual comprehension of OOP and BDD. The essential
simplification which Cucumber provided was that it did not try to
reconcile the tensions between design and implementation. It simply
accepted them and provided a formal bridge from one to the other but
teated them as entirely distinct. The material implementation of that
distinction was the critical intellectual insight that Cucumber
provided which I had found in no other place.

For me the great revelation came when I finally understood that
features faced outward and simply said what should be done without any
reference to how success could be measured. Steps faced inward and
simply determined that what was requested in fact was done. In
consequence the former should look, in my opinion, as much like plain
written language as possible. The latter however, are the province of
the implementors and can look like anything at all because the people
concerned with design should never see them. Thus I have no strong
opinions on whether steps within steps are good or bad, so long as
things that pass values stay entirely in the step_definition files.

My observation is that difficulties with Cucumber and programming with
steps in feature statements often comes from those people who
perpetually straddle both sides of design and implementation. I
suspect that most users of this tool work in very small teams, or
individually like myself. They may have some competence as a domain
expert but often do not. They work mostly for resource constrained
clients whose knowledge of their own business is often astonishingly
shallow ( a case all to common with clients that are not so
constrained ). Because of the blurring of design and implementation
that this circumstance engenders the resulting conflations and
confusions are carried over into the use, or misuse, of feature files
as something akin to a script processor.

We are all always looking for the silver bullet. In the hands of a
truly competent person Cucumber can perform amazing feats of design.
To such a person Cucumber is akin to the silver bullet and naturally
they speak of it as such. Those that learn of Cucumber from these
testimonials naturally desire that they will obtain the same results
with no additional effort on their part. Therein lies the seeds of
disappointment. Like many powerful tools, in the hands of the inexpert
Cucumber can do great harm as well. I am not sure that it is
possible, or desirable, to constrain or expand Cucumber in vain
attempts to protect or indulge the ignorant. There is no substitute
for knowledge.

Cucumber itself comes with no predefined steps. These are invariantly
provided by other projects a a means to incorporate their particular
tool into a Cucumber framework. I cannot see how our position on the
matter will have the slightest influence on those other projects that
provide them.

In short, the root of most of this difficulty is simple want of
copious, lucid, example filled, indexed and cross-referenced
documentation for our tools, be they Cucumber, Capybara, Webrat or
whatever. The writers of such tools are so intimately familiar with
their function that the absence or lamentable quality of their
documentation excites no notice. The users of such products do not
wish to spend more time discovering the intracity of a tool's poorly
documented API then writing productive code. Predefined steps are a
poor substituted for well organized complete documentation but often
that is all one gets to work with and so, that is exactly what we do.

[Andrew Premdas]

Post by byrnejb

Post by Matt Wynne

Post by byrnejb
It does not help that the libraries of steps_definitions distributed
with Cucumber-Rails, Webrat and so forth encourage both step nesting
( reuse ) and imperative feature statements ( When /^I fill in "(.*)"
with "(.*)"$/ do |arg1,arg2| ). These libraries are the first
introduction to step_definitions for most adopters. their appearance
and usage inevitably sets the expectation as to what is 'right'. While
their provision is well intentioned I have come to believe that their
example starts many people down the wrong path with respect to both
step definitions and feature statements.

+1
What are we going to do about it?

Well, I have given this matter some thought in the past and I do not
have a good answer to that question. There may not be one. Cucumber,
by its very nature and design, expresses the tensions between design
and implementation. The two are widely separated spaces,
distinguished not only in purpose but also in concept and language.
In my ever evolving article on the Cucumber wiki ( Cucumber
Backgrounder ) I explore this tension to the best of my current
knowledge but I cannot resolve the different goals that each sets.
I have had a long and difficult road to BDD ( not that I have finished
the journey ), coming as I do from a professional background in heavy
and mid-range iron using mainly 4GLs, central data dictionaries, and
CODASYL databases. The concepts of OOP, TDD and BDD always seemed to
elude me regardless how much effort I expended trying to grasp their
essentials. I came to Ruby after spending four futile years with Java
watching the libraries grow exponentially in that time. I tried
TestUnit, then RSPec, RSpec Stories. Because of that last effort I
happened to be present on the RSpec mailing list when Cucumber was
first broached as an idea.
You can easily follow the evolution of my knowledge thereafter through
the archives of this very mailing list and that of RSpec. It is not
too much to say that for me Cucumber alone provided the entry point
into gradual comprehension of OOP and BDD. The essential
simplification which Cucumber provided was that it did not try to
reconcile the tensions between design and implementation. It simply
accepted them and provided a formal bridge from one to the other but
teated them as entirely distinct. The material implementation of that
distinction was the critical intellectual insight that Cucumber
provided which I had found in no other place.
For me the great revelation came when I finally understood that
features faced outward and simply said what should be done without any
reference to how success could be measured. Steps faced inward and
simply determined that what was requested in fact was done. In
consequence the former should look, in my opinion, as much like plain
written language as possible. The latter however, are the province of
the implementors and can look like anything at all because the people
concerned with design should never see them. Thus I have no strong
opinions on whether steps within steps are good or bad, so long as
things that pass values stay entirely in the step_definition files.
My observation is that difficulties with Cucumber and programming with
steps in feature statements often comes from those people who
perpetually straddle both sides of design and implementation. I
suspect that most users of this tool work in very small teams, or
individually like myself. They may have some competence as a domain
expert but often do not. They work mostly for resource constrained
clients whose knowledge of their own business is often astonishingly
shallow ( a case all to common with clients that are not so
constrained ). Because of the blurring of design and implementation
that this circumstance engenders the resulting conflations and
confusions are carried over into the use, or misuse, of feature files
as something akin to a script processor.
We are all always looking for the silver bullet. In the hands of a
truly competent person Cucumber can perform amazing feats of design.
To such a person Cucumber is akin to the silver bullet and naturally
they speak of it as such. Those that learn of Cucumber from these
testimonials naturally desire that they will obtain the same results
with no additional effort on their part. Therein lies the seeds of
disappointment. Like many powerful tools, in the hands of the inexpert
Cucumber can do great harm as well. I am not sure that it is
possible, or desirable, to constrain or expand Cucumber in vain
attempts to protect or indulge the ignorant. There is no substitute
for knowledge.
Cucumber itself comes with no predefined steps. These are invariantly
provided by other projects a a means to incorporate their particular
tool into a Cucumber framework. I cannot see how our position on the
matter will have the slightest influence on those other projects that
provide them.
In short, the root of most of this difficulty is simple want of
copious, lucid, example filled, indexed and cross-referenced
documentation for our tools, be they Cucumber, Capybara, Webrat or
whatever. The writers of such tools are so intimately familiar with
their function that the absence or lamentable quality of their
documentation excites no notice. The users of such products do not
wish to spend more time discovering the intracity of a tool's poorly
documented API then writing productive code. Predefined steps are a
poor substituted for well organized complete documentation but often
that is all one gets to work with and so, that is exactly what we do.

Thankyou for this most insightful post.

I don't think the step definition libraries can be replaced. I think their
role and affect is very similar to that of generators in Rails. They provide
a quick win, that allows people to start using the tool with good effect
very quickly. However as you become more and more experienced with the tool
you realise that they are actually counter-productive. However if they were
removed the tool would become unusable to new users. In the same way that
Rails would be unusable without generators for new users. The initial
learning curve would be so much steeper, that many would not get past it.

As with Rails generators I think the best solution is just to encourage
people to stop using them. Personally I'm beginning to see them as a smell.
If they're in my feature, then my feature smells and needs refactoring. So
in a way their presence in Cuke is still useful.

Andrew


--

Post by byrnejb
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.

[Eric Pierce]

Post by Andrew Premdas

Cucumber itself comes with no predefined steps.  These are invariantly
provided by other projects a a means to incorporate their particular
tool into a Cucumber framework.  I cannot see how our position on the
matter will have the slightest influence on those other projects that
provide them.

As with Rails generators I think the best solution is just to encourage
people to stop using them. Personally I'm beginning to see them as a smell.
If they're in my feature, then my feature smells and needs refactoring. So
in a way their presence in Cuke is still useful.

It's true, the predefined step definitions from Webrat, Capybara,
email_spec and such were my primary source of examples on how to write
new step definitions. I agree that they are a good starting point, but
they were probably also what led me so deep into the territory of
nesting steps. Refactoring my project to avoid nested steps has led me
to what I believe is a better overall design--I only wish it hadn't
taken so long for me to discover the "right way" to do it. Perhaps we
can encourage the authors of those tools (and the corresponding
predefined steps) to include helper methods, with a stronger emphasis
on step definitions as a mapping layer--this might help to set a
better example for Cucumber newbies.

Post by Andrew Premdas

In short, the root of most of this difficulty is simple want of
copious, lucid, example filled, indexed and cross-referenced
documentation for our tools, be they Cucumber, Capybara, Webrat or
whatever.

Right on! I think I've learned more about step definitions from this
thread than I've learned in all the wiki, book, and tutorial examples
I've come across. More documentation, please! I will gladly pitch in
where I can.

[Andrew Premdas]

Post by Matt Wynne
cheers,
Matt
07974 430184

Post by Eric Pierce
I really dig Cucumber's support for building complex steps out of
simpler ones, but sometimes I wish there was an option to "expand"
those inner steps when they are executed, especially those times when
I have a bug in an inner step--the backtrace can be pretty useless.
What I would like to see is either a command-line option, or something
similar to the 'steps' method (maybe 'macro'?) with a multiline
Given ABC
Then DEF
Given /^ABC$/ do
macro %Q{
Given A
And B
And C
}
end
Then /^DEF$/ do
macro %Q{
Then D
And E
And F
}
end
Given A
And B
And C
Then D
And E
And F
Given ABC
Given A
And B
And C
Then DEF
Then D
And E
And F
In other words, the ABC and DEF steps are just stand-ins for the fully-
expanded inner steps. Nearly identical to the 'steps' syntax, but
evaluated as if the inner steps had been explicitly included in
the .feature file.
The topic of macros was touched upon in an older thread ("Mixing ruby
code and steps %Q{ } in a step definition?") but I have not seen
mention of expanding the steps in the output as I've described above.
I've started poking through the Cucumber code and thinking of ways to
implement this, but I am wondering if anyone else has interest in such
a feature, and also whether it has been discussed or attempted before.
Thoughts?

Andrew, are you going to hold up your sign? ;)

Oops, sorry been neglecting my duties ...

===============
| SAY NO TO |
| NESTED STEPS |
===============
||
||
||
||

Andrew

Post by Matt Wynne
There's been quite a bit of discussion about this before. A lot of us feel
that nesting steps like this is a bit of an anti-pattern. Search the group
for posts by Andrew Premdas and you'll get the picture.
This isn't obviously a great reason, but I also suspect this would be
pretty awkward to build, and right now the internals of Cucumber are
gradually being cleaned up. Until that's done it's hard for us to really
even think about building this kind of thing.
cheers,
Matt
http://blog.mattwynne.net
--
You received this message because you are subscribed to the Google Groups "Cukes" group.
To unsubscribe from this group, send email to
For more options, visit this group at
http://groups.google.com/group/cukes?hl=en.