On 28 Apr 2012, at 17:19, Andrew Premdas wrote:
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.
Freelance programmer & coach