Substeps - macro request for the nth time

4,072 views
Skip to first unread message

aslak hellesoy

unread,
Mar 14, 2013, 7:09:39 PM3/14/13
to Cucumber Users
The request for some sort of macro functionality in Cucumber comes up over and over again.

In the early days we had GivenScenario, which we got rid of [1] and replaced with  the ability to call steps from step definitions [2]. Over time I have grown to dislike this feature as well. 

Cucumber old-timers have realised that the best tool to achieve composition and reuse is the host programming language (Java, Ruby etc). You know - *methods*.

The pattern is simple: For any step/step definition you want to reuse inside a bigger, "macro" one, extract the body to a regular method. Then let the big "macro" stepdef call several such methods.

The main argument for a macro system *outside* the programming language (in Gherkin) is to make it easier for testers who can't code to reuse smaller pieces.

We had that at some point, but we got rid of that too [3].

If we make it easier for testers to cobble together Gherkin with macros I think we'll end up with a mess that is hard to debug (Gherkin isn't a debuggable programming language) and it deepens the crevasse between testers and programmers. This is something we want to avoid.

A recent blog entry [4] and issue [5] brings the topic up again and suggests we implement this in Gherkin again. Is there anything new under the sun here? Haven't we discussed this topic to death already?


Peter DoMySEO

unread,
Mar 14, 2013, 8:17:30 PM3/14/13
to cu...@googlegroups.com
> Am I missing something?
Yes, I guess so. The [4] really makes sence, isn't it?
IMHO - The readability is still preserved, more compact, more flexible.

George Dinwiddie

unread,
Mar 14, 2013, 8:42:11 PM3/14/13
to cu...@googlegroups.com
Aslak,

On 3/14/13 7:09 PM, aslak hellesoy wrote:
> The request for some sort of macro functionality in Cucumber comes up
> over and over again.
>
> In the early days we had GivenScenario, which we got rid of [1] and
> replaced with the ability to call steps from step definitions [2]. Over
> time I have grown to dislike this feature as well.
>
> Cucumber old-timers have realised that the best tool to achieve
> composition and reuse is the host programming language (Java, Ruby etc).
> You know - *methods*.
>
> The pattern is simple: For any step/step definition you want to reuse
> inside a bigger, "macro" one, extract the body to a regular method. Then
> let the big "macro" stepdef call several such methods.
>
> The main argument for a macro system *outside* the programming language
> (in Gherkin) is to make it easier for testers who can't code to reuse
> smaller pieces.

I disagree that this is the main argument. I think the main argument is
to allow refactoring the gherkin, without /necessarily/ rewriting in a
programming language.

I don't think that building elaborate setups, like web steps, is
beneficial. But I don't think that forbidding any crossover point is
beneficial, either. A test suite is always a work in progress. There are
always bits that can be left with a faint smell--and might even be
better that way.

- George



>
> We had that at some point, but we got rid of that too [3].
>
> If we make it easier for testers to cobble together Gherkin with macros
> I think we'll end up with a mess that is hard to debug (Gherkin isn't a
> debuggable programming language) and it deepens the crevasse between
> testers and programmers. This is something we want to avoid.
>
> A recent blog entry [4] and issue [5] brings the topic up again and
> suggests we implement this in Gherkin again. Is there anything new under
> the sun here? Haven't we discussed this topic to death already?
>
> Am I missing something?
>
> Aslak
>
> [1]
> http://blog.josephwilk.net/ruby/cucumber-waves-goodbye-to-givenscenario.html
> [2]
> https://github.com/cucumber/cucumber/wiki/Calling-Steps-from-Step-Definitions
> [3] http://aslakhellesoy.com/post/11055981222/the-training-wheels-came-off
> [4]
> http://www.technophobia.com/blog/read/experiences-with-bdd-and-cucumber-part-ii-substeps-439
> [5] https://github.com/cucumber/cucumber-jvm/issues/483
>
--
----------------------------------------------------------------------
* George Dinwiddie * http://blog.gdinwiddie.com
Software Development http://www.idiacomputing.com
Consultant and Coach http://www.agilemaryland.org
----------------------------------------------------------------------

Andrew Premdas

unread,
Mar 14, 2013, 9:30:38 PM3/14/13
to cu...@googlegroups.com
No I don't think your missing anything. I just think people don't understand Cucumber as well as you do. IMO link 4 is nothing new.

It would be nice if this sort of thing didn't occur, but in a way its inevitable, especially as Cucumber moves to new languages and new people see it and apply their experience to it.

A salutary example of this phenomena is when Jamis Buck wrote a DI framework for Ruby, blogged about lots and then realised it was completely unnecessary. Applying his previous experience to a new setting (Ruby) he thought something was missing, wrote something cool and then wanted to tell the world about it. Unusually after investing all that time in needle, he realised his mistake wrote very publicly about it and then canned it.

Link(4) seems to be embarking on a similar journey I think. At the moment there is lots of proselytising, and yet again macros will gain supporters

Anyhow Aslak as someone who is older and wiser, has experienced this before I think your perfectly justified to see this request and reject it - no matter how well written the blog article is and how pretty are its diagrams, and I'm 110% behind you on this one.

All best

Andrew



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



--
------------------------
Andrew Premdas

aslak hellesoy

unread,
Mar 15, 2013, 3:31:44 AM3/15/13
to Cucumber Users
On Thu, Mar 14, 2013 at 11:09 PM, aslak hellesoy <aslak.h...@gmail.com> wrote:
The request for some sort of macro functionality in Cucumber comes up over and over again.

In the early days we had GivenScenario, which we got rid of [1] and replaced with  the ability to call steps from step definitions [2]. Over time I have grown to dislike this feature as well. 

Cucumber old-timers have realised that the best tool to achieve composition and reuse is the host programming language (Java, Ruby etc). You know - *methods*.

The pattern is simple: For any step/step definition you want to reuse inside a bigger, "macro" one, extract the body to a regular method. Then let the big "macro" stepdef call several such methods.

The main argument for a macro system *outside* the programming language (in Gherkin) is to make it easier for testers who can't code to reuse smaller pieces.

We had that at some point, but we got rid of that too [3].

If we make it easier for testers to cobble together Gherkin with macros I think we'll end up with a mess that is hard to debug (Gherkin isn't a debuggable programming language) and it deepens the crevasse between testers and programmers. This is something we want to avoid.

A recent blog entry [4] and issue [5] brings the topic up again and suggests we implement this in Gherkin again. Is there anything new under the sun here? Haven't we discussed this topic to death already?


For the reference, we have an open ticket in gherkin about this as well:

I have also created a documentation ticket, reminding us to document this:

Aslak

Seb Rose

unread,
Mar 15, 2013, 4:12:06 AM3/15/13
to cu...@googlegroups.com
On 14 March 2013 23:09, aslak hellesoy <aslak.h...@gmail.com> wrote:
> The request for some sort of macro functionality in Cucumber comes up over
> and over again.
>
> In the early days we had GivenScenario, which we got rid of [1] and replaced
> with the ability to call steps from step definitions [2]. Over time I have
> grown to dislike this feature as well.
>
> Cucumber old-timers have realised that the best tool to achieve composition
> and reuse is the host programming language (Java, Ruby etc). You know -
> *methods*.
>
> The pattern is simple: For any step/step definition you want to reuse inside
> a bigger, "macro" one, extract the body to a regular method. Then let the
> big "macro" stepdef call several such methods.
>
> The main argument for a macro system *outside* the programming language (in
> Gherkin) is to make it easier for testers who can't code to reuse smaller
> pieces.

For me, it looks like the claim is that testers should be able to
write programs without using a programming language. And the proposed
solution is...

... to create _yet_ another programming language (one that has none of
the useful tooling that comes with more mature languages).

Programming is programming. I agree with Aslak's position.

>
> We had that at some point, but we got rid of that too [3].
>
> If we make it easier for testers to cobble together Gherkin with macros I
> think we'll end up with a mess that is hard to debug (Gherkin isn't a
> debuggable programming language) and it deepens the crevasse between testers
> and programmers. This is something we want to avoid.
>
> A recent blog entry [4] and issue [5] brings the topic up again and suggests
> we implement this in Gherkin again. Is there anything new under the sun
> here? Haven't we discussed this topic to death already?
>
> Am I missing something?
>
> Aslak
>
> [1]
> http://blog.josephwilk.net/ruby/cucumber-waves-goodbye-to-givenscenario.html
> [2]
> https://github.com/cucumber/cucumber/wiki/Calling-Steps-from-Step-Definitions
> [3] http://aslakhellesoy.com/post/11055981222/the-training-wheels-came-off
> [4]
> http://www.technophobia.com/blog/read/experiences-with-bdd-and-cucumber-part-ii-substeps-439
> [5] https://github.com/cucumber/cucumber-jvm/issues/483
>
> --
> -- Rules --
>
> 1) Please prefix the subject with [Ruby], [JVM] or [JS].
> 2) Please use interleaved answers
> http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
> 3) If you have a question, don't reply to an existing message. Start a new
> topic instead.
>
> You received this message because you are subscribed to the Google Groups
> Cukes group. To post to this group, send email to cu...@googlegroups.com. To
> unsubscribe from this group, send email to
> cukes+un...@googlegroups.com. For more options, visit this group at
> https://groups.google.com/d/forum/cukes?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Cukes" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to cukes+un...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--
ACCU - Professionalism in Programming - http://accu.org

http://www.claysnow.co.uk
http://twitter.com/#!/sebrose
http://uk.linkedin.com/in/sebrose

Matt Wynne

unread,
Mar 15, 2013, 9:22:27 AM3/15/13
to cu...@googlegroups.com
On 14 Mar 2013, at 23:09, aslak hellesoy <aslak.h...@gmail.com> wrote:

The request for some sort of macro functionality in Cucumber comes up over and over again.

In the early days we had GivenScenario, which we got rid of [1] and replaced with  the ability to call steps from step definitions [2]. Over time I have grown to dislike this feature as well. 

Cucumber old-timers have realised that the best tool to achieve composition and reuse is the host programming language (Java, Ruby etc). You know - *methods*.

The pattern is simple: For any step/step definition you want to reuse inside a bigger, "macro" one, extract the body to a regular method. Then let the big "macro" stepdef call several such methods.

The main argument for a macro system *outside* the programming language (in Gherkin) is to make it easier for testers who can't code to reuse smaller pieces.

We had that at some point, but we got rid of that too [3].

If we make it easier for testers to cobble together Gherkin with macros I think we'll end up with a mess that is hard to debug (Gherkin isn't a debuggable programming language) and it deepens the crevasse between testers and programmers. This is something we want to avoid.

A recent blog entry [4] and issue [5] brings the topic up again and suggests we implement this in Gherkin again. Is there anything new under the sun here? Haven't we discussed this topic to death already?

Here's a quote right from the beginning of [4]

> the impact on the development team could be reduced by providing a better framework that enabled the test authors to implement a greater proportion of the tests themselves, independently of the development team.

This snippet reveals quite a lot to me about the blog author's experience with TDD / BDD. Namely:

1) They see a clear separation between 'the development team' and a QA team of 'test authors'
2) They think that doing TDD has an (implicitly negative) impact on that development team
3) They think that having those 'test authors' developing tests 'independently of the development team' is a good idea.

This strikes me as a context where the team are still, basically, building software backwards[6]. Despite what the post says about them building their tests first, I'm not convinced this is a team who can teach me anything new about BDD. When I've seen BDD work, it's because the same people who write the code are involved in writing the tests. This involvement is where the magic happens: it's when you write the test that you get a chance to consider and gain insights into the work you're about to do. A tool that helps reduce this 'burden' seems to me to be entirely misguided.

Using Cucumber does require investment in writing automation code, but my experience is that writing that code teaches us useful things about how easy our system is to automate. Time well spent.

Am I missing something?

I've got three things you might have missed, which come down to competence, trust, and domain learning.

Competence

What you're perhaps missing is the sheer number of teams who use Cucumber but don't have the experience, confidence, or skill to maintain what you or I would call a well-factored step definition / glue code layer. We haven't made nearly enough effort to explain to people how to do this (I hope to remedy this with my talk at CukeUp) and even if we had, so many teams sadly still make test maintenance the responsibility of people who are just not good programmers. People in that situation are naturally going to want a way to do less (apparent) programming.

Trust

Additionally, I think a lot of the imperative vs declarative debate that I see teams have comes down to trust. I sometimes show this scenario as an example of taking the declarative style too far:

  Given the system is running
  When I use the system
  Then it should work, perfectly

This is a joke, but it makes a serious point: if you were to use this scenario for your app, you'd be placing a great deal of trust in whoever wrote the step definition for "it should work, perfectly". If you're reading this scenario, you need to feel that trust in order to actually believe that this behaviour is implemented. Having a way for non-technical people (I would include many QA folk in this) to look beneath the declarative what and see the more imperative how might help those people to trust what the automated tests are doing.

Domain learning

What I have also seen is that the level of abstraction a team wants to use in their scenarios will change over time. Early on in a project when they're still learning about the domain, they'll want to put in a lot of detail. Each new piece of learning feels worth writing down, so their scenarios reflect this. Over time, as they gain more understanding of the domain, they feel safer to imply more things in their descriptions of the behaviour, and the scenarios become more declarative, more abstract.

I think this is natural, and I don't think it's something you can rush, or force. That's the one justifiable reason I can see for having some kind of macro support built into Gherkin, so it's possible to easily and safely refactor scenarios that contain too much detail, to make them more declarative. I can see how it would be abused by a team like the one from [4], and I'm not sure whether that's a trade-off that's worth it. I certainly wouldn't get sucked into adding the equivalent of #step or #steps to Cucumber-JVM; I think that's definitely the wrong approach.



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

Robert

unread,
Mar 20, 2013, 12:08:05 PM3/20/13
to cu...@googlegroups.com
Matt,


On Friday, March 15, 2013 6:22:27 AM UTC-7, Matt Wynne wrote:

On 14 Mar 2013, at 23:09, aslak hellesoy <aslak.h...@gmail.com> wrote:

The request for some sort of macro functionality in Cucumber comes up over and over again.

In the early days we had GivenScenario, which we got rid of [1] and replaced with  the ability to call steps from step definitions [2]. Over time I have grown to dislike this feature as well. 

Cucumber old-timers have realised that the best tool to achieve composition and reuse is the host programming language (Java, Ruby etc). You know - *methods*.

The pattern is simple: For any step/step definition you want to reuse inside a bigger, "macro" one, extract the body to a regular method. Then let the big "macro" stepdef call several such methods.

The main argument for a macro system *outside* the programming language (in Gherkin) is to make it easier for testers who can't code to reuse smaller pieces.

We had that at some point, but we got rid of that too [3].

If we make it easier for testers to cobble together Gherkin with macros I think we'll end up with a mess that is hard to debug (Gherkin isn't a debuggable programming language) and it deepens the crevasse between testers and programmers. This is something we want to avoid.

A recent blog entry [4] and issue [5] brings the topic up again and suggests we implement this in Gherkin again. Is there anything new under the sun here? Haven't we discussed this topic to death already?

Here's a quote right from the beginning of [4]

> the impact on the development team could be reduced by providing a better framework that enabled the test authors to implement a greater proportion of the tests themselves, independently of the development team.

This snippet reveals quite a lot to me about the blog author's experience with TDD / BDD. Namely:

1) They see a clear separation between 'the development team' and a QA team of 'test authors'
2) They think that doing TDD has an (implicitly negative) impact on that development team
3) They think that having those 'test authors' developing tests 'independently of the development team' is a good idea.

This strikes me as a context where the team are still, basically, building software backwards[6]. Despite what the post says about them building their tests first, I'm not convinced this is a team who can teach me anything new about BDD. When I've seen BDD work, it's because the same people who write the code are involved in writing the tests. This involvement is where the magic happens: it's when you write the test that you get a chance to consider and gain insights into the work you're about to do. A tool that helps reduce this 'burden' seems to me to be entirely misguided.

Using Cucumber does require investment in writing automation code, but my experience is that writing that code teaches us useful things about how easy our system is to automate. Time well spent.

Am I missing something?

I've got three things you might have missed, which come down to competence, trust, and domain learning.

Competence

What you're perhaps missing is the sheer number of teams who use Cucumber but don't have the experience, confidence, or skill to maintain what you or I would call a well-factored step definition / glue code layer. We haven't made nearly enough effort to explain to people how to do this (I hope to remedy this with my talk at CukeUp) and even if we had, so many teams sadly still make test maintenance the responsibility of people who are just not good programmers. People in that situation are naturally going to want a way to do less (apparent) programming.


Any plans on making your way to the United States -- specifically, Southern California? We could sure use some sort of conference/workshop to better understand how to use Cucumber.

Matt Wynne

unread,
Mar 21, 2013, 4:47:56 AM3/21/13
to cu...@googlegroups.com
Hi Robert,

That would be lovely. The problem for me is visa restrictions, but make it very hard for me to travel to the USA to do even unpaid teaching or consulting work, let alone paid work.

However there are plenty of people based in the USA who could help, and are active on this list. I'd recommend George Dinwiddie, for example.

Robert

unread,
Mar 21, 2013, 12:49:52 PM3/21/13
to cu...@googlegroups.com
Matt
I see. Sorry to hear that. And, thanks for the contact. I'll reach out to George when we've got some additional traction within our organization surrounding cucumber.
Reply all
Reply to author
Forward
0 new messages