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

ma...@mattwynne.net
07974 430184

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]

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.

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 post to this group, send email to cu...@googlegroups.com.
To unsubscribe from this group, send email to cukes+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cukes?hl=en.

[Eric Pierce]

On Fri, Nov 19, 2010 at 9:18 AM, Matt Wynne <m...@mattwynne.net>
wrote:

> 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."

On Nov 19, 2:40 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
> 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]

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

[George Dinwiddie]

Alas, poor Cucumber, I knew him well.

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).

>> 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.

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.

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
<li...@idiacomputing.com> wrote:
> 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.

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.

>
> 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

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

[George Dinwiddie]

Mike

On 11/19/10 7:06 PM, Mike Sassak wrote:
> On Fri, Nov 19, 2010 at 5:30 PM, George Dinwiddie
> <li...@idiacomputing.com> wrote:
>> 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/

[Eric Pierce]

Mike Sassak wrote:
> 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.

Mike Sassak wrote:
> 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,

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.

[Eric Pierce]

> 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.

[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

On Nov 19, 2:40 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

> On Fri, Nov 19, 2010 at 9:18 AM, Matt Wynne <m...@mattwynne.net> wrote:
>
> > cheers,
> > Matt
>
> > m...@mattwynne.net

> > cukes+un...@googlegroups.com <cukes%2Bunsu...@googlegroups.com>.

[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.

Aslak

[Eric Pierce]

On Nov 20, 1:24 pm, Aslak Hellesøy <aslak.helle...@gmail.com> wrote:
> 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.

[Andrew Premdas]

Oops, sorry been neglecting my duties ...

===============

|    SAY NO TO       |

|  NESTED STEPS  |

===============

              ||

              ||

              ||

              ||

Andrew

 

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

[byrnejb]

On Nov 19, 4:40 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

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

Expediency.

[aslak hellesoy]

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

[George Dinwiddie]

On 11/22/10 11:33 AM, aslak hellesoy wrote:
> > 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."

[aslak hellesoy]

On Mon, Nov 22, 2010 at 6:15 PM, George Dinwiddie <li...@idiacomputing.com> wrote:

On 11/22/10 11:33 AM, aslak hellesoy wrote:

    > 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?

Aslak

 

--
 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


On Nov 22, 8:33 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

> On Sun, Nov 21, 2010 at 8:54 PM, byrnejb <byrn...@harte-lyne.ca> wrote:
> > On Nov 19, 4:40 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
>
> > > 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.
>
>
>
>
>
>
>
> >  --
> > You received this message because you are subscribed to the Google Groups
> > "Cukes" group.
> > To post to this group, send email to cu...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > cukes+un...@googlegroups.com <cukes%2Bunsu...@googlegroups.com>.

[George Dinwiddie]

On 11/22/10 1:36 PM, aslak hellesoy wrote:
>
>
> On Mon, Nov 22, 2010 at 6:15 PM, George Dinwiddie
> <li...@idiacomputing.com <mailto:li...@idiacomputing.com>> wrote:
>
> On 11/22/10 11:33 AM, aslak hellesoy wrote:
>
> > 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

[Matt Wynne]

On 22 Nov 2010, at 19:39, Franklin Webber wrote:

> 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

> On Nov 22, 8:33 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
>> On Sun, Nov 21, 2010 at 8:54 PM, byrnejb <byrn...@harte-lyne.ca> wrote:
>>> On Nov 19, 4:40 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
>>
>>>> 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.
>>
>>
>>
>>
>>
>>
>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Cukes" group.
>>> To post to this group, send email to cu...@googlegroups.com.
>>> To unsubscribe from this group, send email to
>>> cukes+un...@googlegroups.com <cukes%2Bunsu...@googlegroups.com>.
>>> 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.
> To post to this group, send email to cu...@googlegroups.com.

> To unsubscribe from this group, send email to cukes+un...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/cukes?hl=en.
>

cheers,
Matt

ma...@mattwynne.net
07974 430184

[byrnejb]

On Nov 22, 11:33 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:

> On Sun, Nov 21, 2010 at 8:54 PM, byrnejb <byrn...@harte-lyne.ca> wrote:
> > On Nov 19, 4:40 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
>
> > > 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.

[Franklin Webber]

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

[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.

Andrew

[byrnejb]

On Nov 23, 8:33 pm, Andrew Premdas <aprem...@gmail.com> wrote:

>
> 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]

On 22 Nov 2010, at 19:47, George Dinwiddie wrote:

> On 11/22/10 1:36 PM, aslak hellesoy wrote:
>>
>>
>> On Mon, Nov 22, 2010 at 6:15 PM, George Dinwiddie
>> <li...@idiacomputing.com <mailto:li...@idiacomputing.com>> wrote:
>>
>> On 11/22/10 11:33 AM, aslak hellesoy wrote:
>>
>> > 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

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.

[Matt Wynne]

+1

What are we going to do about it?

[George Dinwiddie]

Matt,

On 11/24/10 9:47 AM, Matt Wynne wrote:
> 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?

> 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.

> 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.

> 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.

[Andrew Premdas]

On 24 November 2010 20:16, George Dinwiddie <li...@idiacomputing.com> wrote:

Matt,

On 11/24/10 9:47 AM, Matt Wynne wrote:

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.

Andrew

 

 - 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]

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

 

cheers,
Matt

ma...@mattwynne.net
07974 430184

--

[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

On 11/24/10 6:03 PM, Andrew Premdas wrote:
>
>
> On 24 November 2010 20:16, George Dinwiddie <li...@idiacomputing.com

--

[aslak hellesoy]

On Thu, Nov 25, 2010 at 4:00 PM, George Dinwiddie <li...@idiacomputing.com> wrote:

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

[Eric Pierce]

On Nov 25, 9:21 am, aslak hellesoy <aslak.helle...@gmail.com> wrote:
> 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,

On 11/25/10 11:21 AM, aslak hellesoy wrote:
> (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

[byrnejb]

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.

[Rob Park]

+1

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

[Andrew Premdas]

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

--

[Eric Pierce]

On Nov 28, 1:52 am, Andrew Premdas <aprem...@gmail.com> wrote:

> On 26 November 2010 14:42, byrnejb <byrn...@harte-lyne.ca> wrote:
> > 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.

> On 26 November 2010 14:42, byrnejb <byrn...@harte-lyne.ca> wrote:
> > 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.