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

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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Peter DoMySEO at Mar 15, 2013 at 12:17 am
    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.

    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • George Dinwiddie at Mar 15, 2013 at 12:42 am
    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
    ----------------------------------------------------------------------

    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Premdas at Mar 15, 2013 at 1:30 am
    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


    On 14 March 2013 23:09, 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.

    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 cukes@googlegroups.com.
    To unsubscribe from this group, send email to
    cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.



    --
    ------------------------
    Andrew Premdas
    blog.andrew.premdas.org

    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Mike Howells at Mar 15, 2013 at 6:21 am
    I've previously used 'behave' for Python which allows a step to invoke
    other steps, and I used it to implement "prefix" steps which set some
    context information before invoking another step. This allowed actions to
    be mixed with context setting information as part of the same step, making
    the scenario read more naturally.

    For example, I had the following "prefix" steps that invoke any other step:

    on {date} {step}
    at {time} {step}
    in market {name} {step}
    for {n} times {step}
    every {t} seconds for {n} times {step}
    between {start} and {finish} for {n} times {step}
    on each of the previous {n} days {step}


    These allowed people to write steps like this:

    on 2013-04-22 at 12:30 in market XYZ they bought x10000 of ABC at $12.00

    And I only have to implement the "they bought..." step once for all
    possible combinations of prefixes.

    So being able in a step definition to pass a string into the framework to
    be interpreted as a step would be very useful.

    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Aslak hellesoy at Mar 15, 2013 at 7:32 am

    On Thu, Mar 14, 2013 at 11: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.

    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:
    https://github.com/cucumber/gherkin/issues/178

    I have also created a documentation ticket, reminding us to document this:
    https://github.com/cucumber/cucumber.github.com/issues/21

    Aslak

    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Seb Rose at Mar 15, 2013 at 8:12 am

    On 14 March 2013 23:09, 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.
    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 cukes@googlegroups.com. To
    unsubscribe from this group, send email to
    cukes+unsubscribe@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+unsubscribe@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

    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Wynne at Mar 15, 2013 at 1:22 pm

    On 14 Mar 2013, at 23:09, 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.

    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.
    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
    [6] http://blog.mattwynne.net/2013/02/24/building-software-backwards/

    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    cheers,
    Matt

    --
    http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com




    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert at Mar 20, 2013 at 4:08 pm
    Matt,

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


    On 14 Mar 2013, at 23:09, 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.

    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.


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

    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


    [6] http://blog.mattwynne.net/2013/02/24/building-software-backwards/



    --
    -- 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<javascript:>.
    To unsubscribe from this group, send email to cukes+un...@googlegroups.com<javascript:>.
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.




    cheers,
    Matt

    --
    http://mattwynne.net || https://twitter.com/mattwynne ||
    http://the-cucumber-book.com || http://bddkickstart.com ||
    http://www.relishapp.com



    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Matt Wynne at Mar 21, 2013 at 8:48 am
    Hi Robert,
    On 20 Mar 2013, at 16:08, Robert wrote:

    Matt,


    On Friday, March 15, 2013 6:22:27 AM UTC-7, Matt Wynne wrote:
    On 14 Mar 2013, at 23:09, 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.

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

    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.
    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
    [6] http://blog.mattwynne.net/2013/02/24/building-software-backwards/

    --
    -- 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.
    cheers,
    Matt

    --
    http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com





    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    cheers,
    Matt

    --
    http://mattwynne.net || https://twitter.com/mattwynne || http://the-cucumber-book.com || http://bddkickstart.com || http://www.relishapp.com




    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Robert at Mar 21, 2013 at 4:49 pm
    Matt
    On Thursday, March 21, 2013 1:47:56 AM UTC-7, Matt Wynne wrote:

    Hi Robert,

    On 20 Mar 2013, at 16:08, Robert <rest...@gmail.com <javascript:>> wrote:

    Matt,

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


    On 14 Mar 2013, at 23:09, 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.

    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.


    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.

    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.


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

    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


    [6] http://blog.mattwynne.net/2013/02/24/building-software-backwards/



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




    cheers,
    Matt

    --
    http://mattwynne.net || https://twitter.com/mattwynne ||
    http://the-cucumber-book.com || http://bddkickstart.com ||
    http://www.relishapp.com



    --
    -- 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<javascript:>.
    To unsubscribe from this group, send email to cukes+un...@googlegroups.com<javascript:>.
    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 <javascript:>.
    For more options, visit https://groups.google.com/groups/opt_out.




    cheers,
    Matt

    --
    http://mattwynne.net || https://twitter.com/mattwynne ||
    http://the-cucumber-book.com || http://bddkickstart.com ||
    http://www.relishapp.com



    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michele Martone at Mar 15, 2013 at 8:09 pm

    On Thursday, March 14, 2013 7:09:39 PM UTC-4, Aslak Hellesøy 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?

    Am I missing something?
    Excellent discussion. I have seen this request multiple times through my
    career and I've had to argue against it multiple times. I am a tester and
    so can offer that perspective.

    I don't like this idea for a few reasons. The assumption that testers need
    to be spoon fed some 'easier' solution is one of my pet peeves. Most of
    the testers I know can easily do, or learn how to do the coding needed to
    help with the step definitions.

    I am also concerned with this additional layer because it encourages
    non-agile practices. I've seen people in the past building extra
    functionality into layers to anticipate what the user will need. This
    fails in an agile environment where some of the principals of agile are to
    build only what you need, simply, follow good practices, and refactor when
    necessary.

    I once worked in an non-agile environment that did have this extra layer.
    What ended up happening is that me and a few of the other tech savvy
    testers got tired of waiting for the implementation of substeps and started
    to dive into the code. And we wanted additional detail on how something
    was implemented, and starting to dive into the code. So now we are
    supporting the layer for nothing.

    The macro proposal to me has a larger cost than benefit. Now we need an
    additional tool so testers can find macros. And we need to maintain the
    substep library. I don't see there is enough here that makes this
    worthwhile.

    Just my thoughts.

    Michele

    --
    -- 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 cukes@googlegroups.com. To unsubscribe from this group, send email to cukes+unsubscribe@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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcukes @
postedMar 14, '13 at 11:10p
activeMar 21, '13 at 4:49p
posts12
users9
websitecukes.info
irc#cucumber

People

Translate

site design / logo © 2021 Grokbase