[Ruby] A vision for Cucumber 2.0

334 views
Skip to first unread message

Matt Wynne

unread,
Apr 27, 2012, 5:08:56 AM4/27/12
to cu...@googlegroups.com
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 can read more about what we discussed here:

Any comments?

cheers,
Matt


Andrew Premdas

unread,
Apr 28, 2012, 12:19:13 PM4/28/12
to cu...@googlegroups.com
-- There are two rules:
 
1) Please prefix the subject with [Ruby], [JVM] or [JS]. This allows people to filter messages.
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 
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


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

C0deAttack

unread,
Apr 28, 2012, 1:47:29 PM4/28/12
to cu...@googlegroups.com
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.

Matt Wynne

unread,
Apr 28, 2012, 4:26:49 PM4/28/12
to cu...@googlegroups.com
On 28 Apr 2012, at 17:19, Andrew Premdas wrote:

On 27 April 2012 10:08, Matt Wynne <ma...@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 can read more about what we discussed here:

Any comments?

cheers,
Matt



-- There are two rules:
 
1) Please prefix the subject with [Ruby], [JVM] or [JS]. This allows people to filter messages.
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 
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


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.


Just my thoughts

All best

Andrew




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

-- There are two rules:
 
1) Please prefix the subject with [Ruby], [JVM] or [JS]. This allows people to filter messages.
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 
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

Andy Goundry

unread,
May 17, 2012, 1:17:03 PM5/17/12
to cu...@googlegroups.com
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 <ma...@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 can read more about what we discussed here:

Any comments?

cheers,
Matt


-- There are two rules:
 
1) Please prefix the subject with [Ruby], [JVM] or [JS]. This allows people to filter messages.
2) Please use interleaved answers http://en.wikipedia.org/wiki/Posting_style#Interleaved_style
 
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+unsubscribe@googlegroups.com. For more options, visit this group at https://groups.google.com/d/forum/cukes?hl=en

Tim Walker

unread,
May 17, 2012, 2:17:22 PM5/17/12
to cu...@googlegroups.com
+1

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

Andrew Premdas

unread,
May 17, 2012, 8:05:54 PM5/17/12
to cu...@googlegroups.com
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're doing two things wrong, top posting and using nested steps ;)

Matt Wynne

unread,
May 21, 2012, 5:58:22 PM5/21/12
to cu...@googlegroups.com
Andy,

On 17 May 2012, at 18:17, Andy Goundry 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.

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.

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

Mark Maglana

unread,
May 21, 2012, 9:08:12 PM5/21/12
to cu...@googlegroups.com
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.

Aside from the above, these "nested steps" don't have a need for the Given, When, Then keywords as you will see in my reply to the issue you linked to above (https://github.com/cucumber/gherkin/issues/178#issuecomment-5639228).

Regards,

Mark

Christian Helmbold

unread,
Jun 4, 2013, 5:28:14 AM6/4/13
to cu...@googlegroups.com
Hi Matt,

I just stumbled upon your post and now I am pretty irritated that the tables / scenario outlines should disappear in Cucumber 2.0! Tables are very clear to specify certain aspects which would require lots of repeated texts otherwise.

I would stop using cucumber without this feature, so please don't remove it.

Christian

aslak hellesoy

unread,
Jun 4, 2013, 7:48:47 AM6/4/13
to Cucumber Users
Don't worry Christian. Tablesand Scenario Outlines won't be removed. What's listed in Matt's blog post is ideas worth discussing, not final decisions.

Aslak
 
Christian

--
-- Rules --

 
1) Please prefix the subject with [Ruby], [JVM] or [JS].
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.
 
 

aslak hellesoy

unread,
Jun 4, 2013, 10:03:26 AM6/4/13
to cu...@googlegroups.com


On Tuesday, June 4, 2013, Rodrigo Martin wrote:
I'm here to express my support for Scenario Outlines / Tables ! 


No need. See my reply to Christian.
 
Cheers,
Rodrigo.


El viernes, 27 de abril de 2012 06:08:56 UTC-3, Matt Wynne escribió:
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 

--
Reply all
Reply to author
Forward
0 new messages