Re: [Ruby] A vision for Cucumber 2.0

[Tobias Hahn]

Hey Matt,

Am 28.04.2012 um 10:59 schrieb <cu...@googlegroups.com>:

> Matt Wynne <ma...@mattwynne.net> Apr 27 10:08AM +0100
>
> I don't normally like it when people pimp their blog posts to this list, but I think this one is quite important.

I'll take it from this that I may cross-post my reply to your post here as well ;)

> 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:
> http://blog.mattwynne.net/2012/04/26/a-vision-for-cucumber-2-0/
>
> Any comments?

we’re using Cucumber to develop and maintain a large (~1-2 MLOC) consumer application written in C++.

We depend on the wire protocol as an interface into our application. We like having ruby as an intermediate layer for step definitions. Our strategy is to implement ‘atomic’ user operation as ruby steps, and then combine these atoms into more complex compound steps to dry scenarios and make them more readable and robust. We also use quite a few scenario outlines.

I can understand the desire to make a clean cut and start over. It’s everything my colleagues and I moan for every day.

The number one reason we love Cucumber so much is that is has made testing our application so dead easy (after overcoming an initial integration cost). I fear that if you decide to take all these features away which we depend on so heavily, following you to Cucumber 2.0 would become too expensive for our team.

We simply don’t have the resources to write or maintain our own C++-port of Cucumber.

I would like to ask you to not forget about an upgrade path for existing users of Cucumber.

Best wishes,
Tobias


Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
Sitz (Registered Office) Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838
Vorstand (Management Board): Gerhard Behles, Jan Bohl, Bernd Roggendorf
Vorsitzender des Aufsichtsrats (Chair of the Supervisory Board): Uwe Struck

[Matt Wynne]

On 3 May 2012, at 12:10, Tobias Hahn wrote:

Hey Matt,

Am 28.04.2012 um 10:59 schrieb <cu...@googlegroups.com>:

Matt Wynne <ma...@mattwynne.net> Apr 27 10:08AM +0100  

I don't normally like it when people pimp their blog posts to this list, but I think this one is quite important.

I'll take it from this that I may cross-post my reply to your post here as well ;)

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:

http://blog.mattwynne.net/2012/04/26/a-vision-for-cucumber-2-0/

Any comments?

we’re using Cucumber to develop and maintain a large (~1-2 MLOC) consumer application written in C++.

We depend on the wire protocol as an interface into our application. We like having ruby as an intermediate layer for step definitions. Our strategy is to implement ‘atomic’ user operation as ruby steps, and then combine these atoms into more complex compound steps to dry scenarios and make them more readable and robust. We also use quite a few scenario outlines.

I can understand the desire to make a clean cut and start over. It’s everything my colleagues and I moan for every day.

The number one reason we love Cucumber so much is that is has made testing our application so dead easy (after overcoming an initial integration cost). I fear that if you decide to take all these features away which we depend on so heavily, following you to Cucumber 2.0 would become too expensive for our team.

We simply don’t have the resources to write or maintain our own C++-port of Cucumber.

I would like to ask you to not forget about an upgrade path for existing users of Cucumber.

Thanks for coming here to reply Tobias, I don't find my blog comments is a very nice medium for discussions - this is a much better place.

Bear in mind that the write-up was my record of what everyone had said in the discussion, not necessarily my own opinions. I wrote most of the wire protocol code, and I'm proud of it. I also know people who've written plugins for Flash, for LUA and I'm really glad to hear you're making good use of it too.

My view is that all back-ends, whether it's the wire protocol, the classic manner of defining steps in Ruby, or some new-fangled thing, should all be pluggable in Cucumber 2.0. They won't need to be part of the core codebase, but they'll be supported, and maintained as separate gems. That's my vision, and I realise I didn't make that clear enough in the original post.

Does that make you feel better? :)

cheers,

Matt

--
Freelance programmer & coach
Author, http://pragprog.com/book/hwcuc/the-cucumber-book
Founder, http://www.relishapp.com/
Twitter, https://twitter.com/mattwynne

[Tobias Hahn]

Hey Matt,

> Matt Wynne <ma...@mattwynne.net> May 03 10:56PM +0100

>
> Bear in mind that the write-up was my record of what everyone had said in the discussion, not necessarily my own opinions. I wrote most of the wire protocol code, and I'm proud of it. I also know people who've written plugins for Flash, for LUA and I'm really glad to hear you're making good use of it too.
>
> My view is that all back-ends, whether it's the wire protocol, the classic manner of defining steps in Ruby, or some new-fangled thing, should all be pluggable in Cucumber 2.0. They won't need to be part of the core codebase, but they'll be supported, and maintained as separate gems. That's my vision, and I realise I didn't make that clear enough in the original post.

thanks for clarifying this point. It wasn't clear to me from your original post that you intend to refactor cucumber into a core gem and supporting components into separate gems.

> Does that make you feel better? :)

That does indeed make me feel _much_ better, and it's a big relief :)

Best,

[aslak hellesoy]

On Fri, May 4, 2012 at 10:19 AM, Tobias Hahn <tobia...@ableton.com> wrote:
> Hey Matt,
>
>> Matt Wynne <ma...@mattwynne.net> May 03 10:56PM +0100
>>
>> Bear in mind that the write-up was my record of what everyone had said in the discussion, not necessarily my own opinions. I wrote most of the wire protocol code, and I'm proud of it. I also know people who've written plugins for Flash, for LUA and I'm really glad to hear you're making good use of it too.
>>
>> My view is that all back-ends, whether it's the wire protocol, the classic manner of defining steps in Ruby, or some new-fangled thing, should all be pluggable in Cucumber 2.0. They won't need to be part of the core codebase, but they'll be supported, and maintained as separate gems. That's my vision, and I realise I didn't make that clear enough in the original post.
>
> thanks for clarifying this point. It wasn't clear to me from your original post that you intend to refactor cucumber into a core gem and supporting components into separate gems.
>
>> Does that make you feel better? :)
>
> That does indeed make me feel _much_ better, and it's a big relief :)
>

One thing that we might do as well is to implement a WireBackend in
Cucumber-JVM and package it all up as a self-contained executable jar
file.
If we do that it would use the exact same protocol.

It could also be interesting to build a MsgPackBackend (using
http://msgpack.org/). It's supported by a lot of platforms and could
potentially make it a little easier to add new wire backends.

In any case, the wire protocol will definitely live on!

Aslak

> Best,
> Tobias
>
>
> Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany
> Sitz (Registered Office) Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838
> Vorstand (Management Board): Gerhard Behles, Jan Bohl, Bernd Roggendorf
> Vorsitzender des Aufsichtsrats (Chair of the Supervisory Board): Uwe Struck
>

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