I don't normally like it when people pimp their blog posts to this list, but I think this one is quite important.
At last month’s CukeUp conference, I held a panel discussion between Aslak Hellesoy, Julien Biezemans, Oriol Gual and Jonas Nicklas. I chose these panelists because each of them has written a variation on the original Ruby Cucumber, and I wanted to try to pull these ideas together into a vision for Cucumber 2.0.
> 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
Wish I'd been at Cukeup, especially with all the support for the end of
nested steps!!! Obviously I'd support them being ditched in Cucumber 2.0.
I think people misunderstand Cucumber.World. The idea of a single test
domain for an application is a good thing. I'm pretty ignorant about
Spinach, but from what I've read its got things completely wrong. It allows
your test domain to use the same name for different things e.g. in one
feature a User might be an administrator and in another feature a user
might be a Customer, allowing you to reuse Given I am a user. IMO this is
madness. One of the most important points about writing Cucumber features
is to identify and name distinctly concepts that are important to your
application.
Parallel execution is really important. Anything that could be done to make
this easier would be of great benefit
Single feature execution speed. IMO this is even more important -
particularly for Cucumber-Rails. Cucumber-Rails should aim to run a single
feature in less than 1/2 second. I'd allow a slow first load, but after
that I should be able to change anything in the test domain and most things
in the Rails domain, and get my next run in 1/2 second.
I have no problem with cucumber.yml, and use it to write my own profiles
I think Given When Then And should remain as they are
I'd be interested to see an annotation based step def solution. I assume
this would not allow step def nesting (obviously you can call the methods
by their names, but allowing calls by their annotations would be a big NoNo)
Scenario outlines can go as any scenario outline can be named and
implemented as a single feature in which the outlines are defined in a step
def. i.e. you can go up a level of abstraction if you don't want to write
separate features.
Overall a much simpler Cucumber could be attractive to a wider audience and
easier for the team to implement. The issue of legacy support though is
difficult, but perhaps that should be left in Cucumber 1.x. As spinach and
other cucumber derived frameworks have shown putting together an entirely
new Cucumber, rather than an upgrade is feasible.
Just my thoughts
All best
Andrew
-- ------------------------
Andrew Premdas
blog.andrew.premdas.org
Personally, I quite like the Scenario Outlines. I think it's better to see the different inputs and expected outputs in a Feature. It can help the testers, BA, stakeholders to think about edge cases when creating the scenario. I would hate to see a Feature full of copy+pasted scenarios with a few arguments modified, I think that's worse from a readability point of view.
> On 27 April 2012 10:08, Matt Wynne <m...@mattwynne.net> wrote:
> I don't normally like it when people pimp their blog posts to this list, but I think this one is quite important.
> At last month’s CukeUp conference, I held a panel discussion between Aslak Hellesoy, Julien Biezemans, Oriol Gual and Jonas Nicklas. I chose these panelists because each of them has written a variation on the original Ruby Cucumber, and I wanted to try to pull these ideas together into a vision for Cucumber 2.0.
> 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
> Wish I'd been at Cukeup, especially with all the support for the end of nested steps!!! Obviously I'd support them being ditched in Cucumber 2.0.
I'm ambivalent about this. I don't use them myself, but I can see why people want to. I don't like the current implementation though, and I'd prefer to see it move out into an opt-in plugin rather than being part of cucumber out of the box.
> I think people misunderstand Cucumber.World. The idea of a single test domain for an application is a good thing. I'm pretty ignorant about Spinach, but from what I've read its got things completely wrong. It allows your test domain to use the same name for different things e.g. in one feature a User might be an administrator and in another feature a user might be a Customer, allowing you to reuse Given I am a user. IMO this is madness. One of the most important points about writing Cucumber features is to identify and name distinctly concepts that are important to your application.
Yes, that came up in our discussion. Oriol agreed with this, and I think the main idea we took from Spinach was that step definitions should be mapped into proper Ruby objects instead of flat anonymous blocks. But global language should definitely stay.
> Parallel execution is really important. Anything that could be done to make this easier would be of great benefit
> Single feature execution speed. IMO this is even more important - particularly for Cucumber-Rails. Cucumber-Rails should aim to run a single feature in less than 1/2 second. I'd allow a slow first load, but after that I should be able to change anything in the test domain and most things in the Rails domain, and get my next run in 1/2 second.
That's why I'd like to rebuild it as a library. Re-running Cukes in a Rails app should be just as fast as hitting F5 in your browser in development mode.
> I have no problem with cucumber.yml, and use it to write my own profiles
Have you ever tried to change the configuration code though? It's a total mess.
> I think Given When Then And should remain as they are
I agree with that too. My blog post simply recorded what everyone said!
> I'd be interested to see an annotation based step def solution. I assume this would not allow step def nesting (obviously you can call the methods by their names, but allowing calls by their annotations would be a big NoNo)
There is a private repo (textmapper) that Mike Sassak create back at the end of last year when The Cucumber Book was almost published. We asked him to keep it quiet at the time because we didn't want the publishers to get worried we were going to 'do an RSpec' and have to re-write the book! We'll make it public as soon as Aslak gets a chance.
I'm not saying textmapper is the final answer for what Cucumber 2.0's text -> Ruby mapping should be, but it's probably my favourite of all the ones I've seen. My view is that we should support pluggable back-ends anyway, so that we can also support a 'Classic' back end for backwards compatibility, and also the wire protocol.
> Scenario outlines can go as any scenario outline can be named and implemented as a single feature in which the outlines are defined in a step def. i.e. you can go up a level of abstraction if you don't want to write separate features.
TBH, these aren't very hard to support, and you only need to watch the twitter feedback about my blog posts to see how popular they are. I'm happy for them to stay.
> Overall a much simpler Cucumber could be attractive to a wider audience and easier for the team to implement. The issue of legacy support though is difficult, but perhaps that should be left in Cucumber 1.x. As spinach and other cucumber derived frameworks have shown putting together an entirely new Cucumber, rather than an upgrade is feasible.
Yes, let's start with the assumption that all features have to justify their value again for 2.0.
> 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
I must be doing something wrong as i like nested steps. i find that that they allow me to abstract as much as possible from the feature into a step without that sudden drop to regex and complex looking steps that non-techies find difficult to understand. a step that is readable (as it calls other steps) seems like a nice bridge between feature and a set of raw specs.
Thanks for the hard work and i also wish i'd been there.
>> 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
> Wish I'd been at Cukeup, especially with all the support for the end of > nested steps!!! Obviously I'd support them being ditched in Cucumber 2.0.
> I think people misunderstand Cucumber.World. The idea of a single test > domain for an application is a good thing. I'm pretty ignorant about > Spinach, but from what I've read its got things completely wrong. It allows > your test domain to use the same name for different things e.g. in one > feature a User might be an administrator and in another feature a user > might be a Customer, allowing you to reuse Given I am a user. IMO this is > madness. One of the most important points about writing Cucumber features > is to identify and name distinctly concepts that are important to your > application.
> Parallel execution is really important. Anything that could be done to > make this easier would be of great benefit
> Single feature execution speed. IMO this is even more important - > particularly for Cucumber-Rails. Cucumber-Rails should aim to run a single > feature in less than 1/2 second. I'd allow a slow first load, but after > that I should be able to change anything in the test domain and most things > in the Rails domain, and get my next run in 1/2 second.
> I have no problem with cucumber.yml, and use it to write my own profiles
> I think Given When Then And should remain as they are
> I'd be interested to see an annotation based step def solution. I assume > this would not allow step def nesting (obviously you can call the methods > by their names, but allowing calls by their annotations would be a big NoNo)
> Scenario outlines can go as any scenario outline can be named and > implemented as a single feature in which the outlines are defined in a step > def. i.e. you can go up a level of abstraction if you don't want to write > separate features.
> Overall a much simpler Cucumber could be attractive to a wider audience > and easier for the team to implement. The issue of legacy support though is > difficult, but perhaps that should be left in Cucumber 1.x. As spinach and > other cucumber derived frameworks have shown putting together an entirely > new Cucumber, rather than an upgrade is feasible.
> Just my thoughts
> All best
> Andrew
> -- > ------------------------
> Andrew Premdas
> blog.andrew.premdas.org
On Thu, May 17, 2012 at 11:17 AM, Andy Goundry <m...@andygoundry.com> wrote:
> I must be doing something wrong as i like nested steps. i find that that
> they allow me to abstract as much as possible from the feature into a step
> without that sudden drop to regex and complex looking steps that
> non-techies find difficult to understand. a step that is readable (as it
> calls other steps) seems like a nice bridge between feature and a set of
> raw specs.
> Thanks for the hard work and i also wish i'd been there.
> Andy
> On Saturday, April 28, 2012 5:19:13 PM UTC+1, apremdas wrote:
>> On 27 April 2012 10:08, Matt Wynne <m...@mattwynne.net> wrote:
>>> I don't normally like it when people pimp their blog posts to this list,
>>> but I think this one is quite important.
>>> 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<cukes%2Bunsubscribe@googlegroups.com>.
>>> For more options, visit this group at https://groups.google.com/d/** >>> forum/cukes?hl=en <https://groups.google.com/d/forum/cukes?hl=en>
>> Wish I'd been at Cukeup, especially with all the support for the end of
>> nested steps!!! Obviously I'd support them being ditched in Cucumber 2.0.
>> I think people misunderstand Cucumber.World. The idea of a single test
>> domain for an application is a good thing. I'm pretty ignorant about
>> Spinach, but from what I've read its got things completely wrong. It allows
>> your test domain to use the same name for different things e.g. in one
>> feature a User might be an administrator and in another feature a user
>> might be a Customer, allowing you to reuse Given I am a user. IMO this is
>> madness. One of the most important points about writing Cucumber features
>> is to identify and name distinctly concepts that are important to your
>> application.
>> Parallel execution is really important. Anything that could be done to
>> make this easier would be of great benefit
>> Single feature execution speed. IMO this is even more important -
>> particularly for Cucumber-Rails. Cucumber-Rails should aim to run a single
>> feature in less than 1/2 second. I'd allow a slow first load, but after
>> that I should be able to change anything in the test domain and most things
>> in the Rails domain, and get my next run in 1/2 second.
>> I have no problem with cucumber.yml, and use it to write my own profiles
>> I think Given When Then And should remain as they are
>> I'd be interested to see an annotation based step def solution. I assume
>> this would not allow step def nesting (obviously you can call the methods
>> by their names, but allowing calls by their annotations would be a big NoNo)
>> Scenario outlines can go as any scenario outline can be named and
>> implemented as a single feature in which the outlines are defined in a step
>> def. i.e. you can go up a level of abstraction if you don't want to write
>> separate features.
>> Overall a much simpler Cucumber could be attractive to a wider audience
>> and easier for the team to implement. The issue of legacy support though is
>> difficult, but perhaps that should be left in Cucumber 1.x. As spinach and
>> other cucumber derived frameworks have shown putting together an entirely
>> new Cucumber, rather than an upgrade is feasible.
>> Just my thoughts
>> All best
>> Andrew
>> --
>> ------------------------
>> Andrew Premdas
>> blog.andrew.premdas.org
> 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
> I must be doing something wrong as i like nested steps. i find that that
> they allow me to abstract as much as possible from the feature into a step
> without that sudden drop to regex and complex looking steps that
> non-techies find difficult to understand. a step that is readable (as it
> calls other steps) seems like a nice bridge between feature and a set of
> raw specs.
> Thanks for the hard work and i also wish i'd been there.
> Andy
> On Saturday, April 28, 2012 5:19:13 PM UTC+1, apremdas wrote:
>> On 27 April 2012 10:08, Matt Wynne <m...@mattwynne.net> wrote:
>>> I don't normally like it when people pimp their blog posts to this list,
>>> but I think this one is quite important.
>>> 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<cukes%2Bunsubscribe@googlegroups.com>.
>>> For more options, visit this group at https://groups.google.com/d/** >>> forum/cukes?hl=en <https://groups.google.com/d/forum/cukes?hl=en>
>> Wish I'd been at Cukeup, especially with all the support for the end of
>> nested steps!!! Obviously I'd support them being ditched in Cucumber 2.0.
>> I think people misunderstand Cucumber.World. The idea of a single test
>> domain for an application is a good thing. I'm pretty ignorant about
>> Spinach, but from what I've read its got things completely wrong. It allows
>> your test domain to use the same name for different things e.g. in one
>> feature a User might be an administrator and in another feature a user
>> might be a Customer, allowing you to reuse Given I am a user. IMO this is
>> madness. One of the most important points about writing Cucumber features
>> is to identify and name distinctly concepts that are important to your
>> application.
>> Parallel execution is really important. Anything that could be done to
>> make this easier would be of great benefit
>> Single feature execution speed. IMO this is even more important -
>> particularly for Cucumber-Rails. Cucumber-Rails should aim to run a single
>> feature in less than 1/2 second. I'd allow a slow first load, but after
>> that I should be able to change anything in the test domain and most things
>> in the Rails domain, and get my next run in 1/2 second.
>> I have no problem with cucumber.yml, and use it to write my own profiles
>> I think Given When Then And should remain as they are
>> I'd be interested to see an annotation based step def solution. I assume
>> this would not allow step def nesting (obviously you can call the methods
>> by their names, but allowing calls by their annotations would be a big NoNo)
>> Scenario outlines can go as any scenario outline can be named and
>> implemented as a single feature in which the outlines are defined in a step
>> def. i.e. you can go up a level of abstraction if you don't want to write
>> separate features.
>> Overall a much simpler Cucumber could be attractive to a wider audience
>> and easier for the team to implement. The issue of legacy support though is
>> difficult, but perhaps that should be left in Cucumber 1.x. As spinach and
>> other cucumber derived frameworks have shown putting together an entirely
>> new Cucumber, rather than an upgrade is feasible.
>> Just my thoughts
>> All best
>> Andrew
>> --
>> ------------------------
>> Andrew Premdas
>> blog.andrew.premdas.org
> 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're doing two things wrong, top posting and using nested steps ;)
All best
Andrew
-- ------------------------
Andrew Premdas
blog.andrew.premdas.org
> I must be doing something wrong as i like nested steps. i find that that they allow me to abstract as much as possible from the feature into a step without that sudden drop to regex and complex looking steps that non-techies find difficult to understand. a step that is readable (as it calls other steps) seems like a nice bridge between feature and a set of raw specs.
> Thanks for the hard work and i also wish i'd been there.
I don't personally use nested steps, but I can understand why people want them. My view is that they belong in the business-readable / Gherkin domain rather than the technical step-definition / Ruby domain, which is why I have proposed this addition to the Gherkin syntax: https://github.com/cucumber/gherkin/issues/178
Please chip in on that ticket if you have anything to add.
> On Saturday, April 28, 2012 5:19:13 PM UTC+1, apremdas wrote:
> On 27 April 2012 10:08, Matt Wynne <m...@mattwynne.net> wrote:
> I don't normally like it when people pimp their blog posts to this list, but I think this one is quite important.
> At last month’s CukeUp conference, I held a panel discussion between Aslak Hellesoy, Julien Biezemans, Oriol Gual and Jonas Nicklas. I chose these panelists because each of them has written a variation on the original Ruby Cucumber, and I wanted to try to pull these ideas together into a vision for Cucumber 2.0.
> 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
> Wish I'd been at Cukeup, especially with all the support for the end of nested steps!!! Obviously I'd support them being ditched in Cucumber 2.0.
> I think people misunderstand Cucumber.World. The idea of a single test domain for an application is a good thing. I'm pretty ignorant about Spinach, but from what I've read its got things completely wrong. It allows your test domain to use the same name for different things e.g. in one feature a User might be an administrator and in another feature a user might be a Customer, allowing you to reuse Given I am a user. IMO this is madness. One of the most important points about writing Cucumber features is to identify and name distinctly concepts that are important to your application.
> Parallel execution is really important. Anything that could be done to make this easier would be of great benefit
> Single feature execution speed. IMO this is even more important - particularly for Cucumber-Rails. Cucumber-Rails should aim to run a single feature in less than 1/2 second. I'd allow a slow first load, but after that I should be able to change anything in the test domain and most things in the Rails domain, and get my next run in 1/2 second.
> I have no problem with cucumber.yml, and use it to write my own profiles
> I think Given When Then And should remain as they are
> I'd be interested to see an annotation based step def solution. I assume this would not allow step def nesting (obviously you can call the methods by their names, but allowing calls by their annotations would be a big NoNo)
> Scenario outlines can go as any scenario outline can be named and implemented as a single feature in which the outlines are defined in a step def. i.e. you can go up a level of abstraction if you don't want to write separate features.
> Overall a much simpler Cucumber could be attractive to a wider audience and easier for the team to implement. The issue of legacy support though is difficult, but perhaps that should be left in Cucumber 1.x. As spinach and other cucumber derived frameworks have shown putting together an entirely new Cucumber, rather than an upgrade is feasible.
> Just my thoughts
> All best
> Andrew
> -- > ------------------------
> Andrew Premdas
> blog.andrew.premdas.org
> 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
> I don't personally use nested steps, but I can understand why people want
> them. My view is that they belong in the business-readable / Gherkin domain
> rather than the technical step-definition / Ruby domain, which is why I
> have proposed this addition to the Gherkin syntax:
> https://github.com/cucumber/gherkin/issues/178
Matt,
I don't think this belongs to the business domain at all, but rather to the
"app tester" domain which is a lot like what web_steps.rb used to be. Thus
I think that mixing this with Gherkin is a bad idea as it will only bring
back the problems introduced by web_steps.
