[Cucumber] Substeps - macro request for the nth time

Yes, I guess so. The [4] really makes sence, isn't it?
IMHO - The readability is still preserved, more compact, more flexible.

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

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

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.

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

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.

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

Matt,


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.

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

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.

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