On Thu, May 17, 2012 at 11:17 AM, Andy Goundry <m...
> 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.
> 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 <http://aslakhellesoy.com/>, Julien Biezemans<http://jbpros.net/>
>>> , Oriol Gual <http://oriolgual.me/> and Jonas Nicklas<https://github.com/jnicklas>.
>>> I chose these panelists because each of them has written a variation<http://github.com/cucumber/cucumber-jvm>
>>> on <https://github.com/cucumber/cucumber-js> the<https://github.com/codegram/spinach>
>>> original <https://github.com/jnicklas/turnip> **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?
>>> Freelance programmer & coach
>>> Author, http://pragprog.com/**book/hwcuc/the-cucumber-book<http://pragprog.com/book/hwcuc/the-cucumber-book>
>>> Founder, http://www.relishapp.**com/ <http://www.relishapp.com/>
>>> Twitter, https://twitter.com/**mattwynne <https://twitter.com/mattwynne>
>>> -- 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/**
>>> You received this message because you are subscribed to the Google
>>> Groups Cukes group. To post to this group, send email to
>>> email@example.com. To unsubscribe from this group, send email to
>>> 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
>> 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 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
> You received this message because you are subscribed to the Google Groups
> Cukes group. To post to this group, send email to firstname.lastname@example.org.
> To unsubscribe from this group, send email to
> email@example.com. For more options, visit this group at