Cucumber Wire Protocol and .NET (and Python)
aslak hellesoy
I have rounded up some fine chaps from BEKK (Anders and Åsmund) who are eager to help out with Cucumber support for .NET. Also copying in Chris Kooken who contacted me about .NET and Tim Ottinger who gave me some great Python tips at the Agile 2009 conference (see below).
Please sign up to the cukes mailing list and continue the discussion here if you want to chip in.
At Agile 2009 a couple of weeks ago I met up with Matt Wynne and Richard Lawrence. We talked about how to bring Cucumber to .NET and agreed that IronRuby is not yet mature enough. Users would get a poor user experience of cucumber due to IronRuby's slow performance and unresolved bugs. Richard had the great idea to use a wire protocol similar to Fitnesse's SLIM: http://fitnesse.org/FitNesse.SliM
This would make it possible to use Cucumber with a different programming language than Ruby without relying on "bridges" like IronRuby or JRuby. Step Definitions would run in an external process and cucumber would talk to them over a socket.
We did consider using SLIM, since there are already implementations in several languages for this protocol. However, we decided not to because we think we'll have more control if we invent our own protocol. It turns out to be rather simple - 3-4 API calls implemented in JSON over sockets. You can read more about this here: https://rspec.lighthouseapp.com/projects/16211/tickets/428-wire-protocol
Matt has started a wire-protocol branch in his cucumber fork that's not merged into master yet. It includes the client side of the protocol plus a reference implementation in Ruby. (Nobody will actually use this reference implementation, since it's better to run in-process on Ruby - it's just used for testing and as a reference for implementations in other programming languages). I'll merge this into cucumber's master branch when we have the first working non-ruby implementation in a different programming language - most likely .NET.
Richard has done some fine work on this, and I think this is where Anders and Åsmund (and Chris) could help out. Both on the code side as well as documenting it in the Cuke4Nuke wiki. It lives here:
http://github.com/richardlawrence/Cuke4Nuke
I also had a drunken (at least on my part) convo with Tim Ottinger about Cucumber support for Python. He gave me some great tips. I'd love to see a Python implementaton of this protocol at a later stage - maybe leveraging http://www.python.org/dev/peps/pep-0318/ and a similar approach as Java Step Definitions: http://wiki.github.com/aslakhellesoy/cuke4duke/pure-java-step-definitions. I'll probably hold off on the Python side until the wire protocol stabilises and is working on .NET though.
You probably have lots of questions about what to do, where to start etc. Let's hear them and get started! And if you don't want to/have time to contribute, just remain silent ;-)
Cheers,
Aslak
aslak hellesoy
Not sure it's the best place for it, but there's a brief backlog at
the bottom of the Cuke4Nuke README if anyone is looking for a place to
start contributing.
That's great Richard. I recommend you move these TODOs into tickets in the Github tracker. You can then create tags for each contributor and assign tickets to different people simply by tagging a ticket. Only you can edit tags of a ticket, so the volunteers would have to tell you that they plan on working on a particular feature. (This mailing list is ok for that).
Aslak
Thanks,
Richard
aslak hellesoy
Maybe you could fork Richard's repo and refactor it to use lambdas instead?
(From now on I'll drop the CC in this thread and just send to the list. Please turn on plain text email if you have the chance. It makes it easier to read on mobile devices and easier to reply inline).
Aslak
We have a pretty rough around the edges working prototype, and we used lambda’s to achieve the same look that users do in ruby. Then used reflection to look through all classes in the assembly that derive from keyword base.
public class StepTests : KeywordBase
{
public StepTests()
{
Given("^My Name is \"([^\"]*)\"$", (name) =>
{
throw new Exception("exception");
});
Given("^I live at \"([^\"]*)\"$", (location) =>
{
Console.WriteLine("Location is: " + location);
});
Given("^My city is \"([^\"]*)\" and my state is \"([^\"]*)\"$", (city, state) =>
{
Console.WriteLine("City is: " + city);
Console.WriteLine("State is: " + state);
});
}
}
I think we can do something together for sure. Let me know what you think.
~C hris
Stephen Eley
<aslak.h...@gmail.com> wrote:
>
> We did consider using SLIM, since there are already implementations in
> several languages for this protocol. However, we decided not to because we
> think we'll have more control if we invent our own protocol. It turns out to
> be rather simple - 3-4 API calls implemented in JSON over sockets. You can
> read more about this here:
> https://rspec.lighthouseapp.com/projects/16211/tickets/428-wire-protocol
Brainstorming thought: instead of bare sockets, what about a REST
standard? For Ruby implementations, Rack and Sinatra would make this
nearly trivial. I'm sure any other modern language you'd want to
develop a listener in already has one or more lightweight HTTP server
libraries as well, adding minimal overhead.
The gain would be flexibility. On the server side, it could make it
easy to extend the step invoker, to patch in other middleware for
authentication/caching/logging/etc. as appropriate, or to embed it in
an app that was already Web-enabled instead of having to fire up a
separate listener. Again, that's my Ruby and Rack brain at work, but
other platforms have their own bags of tricks.
On the client side, it would make it easier to write clients other
than the current Cucumber library. Either for different platforms
(Javascript? iPhone? Dashboard widget?) or for a totally different
sort of story runner (a GUI one? a formal logic one? a globally
distributed one? who knows what someone could think of?).
Of course, making it easier to run steps in ways other than Cucumber
may not be your goal. Again, just brainstorming. My point is just
that with current tools, implementing APIs as Web services instead of
wire protocols isn't really harder, and can make a lot of things
easier.
--
Have Fun,
Steve Eley (sfe...@gmail.com)
ESCAPE POD - The Science Fiction Podcast Magazine
http://www.escapepod.org
Anders Hammervold
I am new to using github but will check out the repositories now.
This is very promising.
With regards,
Anders Hammervold
On Sep 12, 7:48 pm, aslak hellesoy <aslak.helle...@gmail.com> wrote:
> I have to say I like the lambda syntax a lot more than the C# Attributes. It
> deck).
>
> Maybe you could fork Richard's repo and refactor it to use lambdas instead?
>
> (From now on I'll drop the CC in this thread and just send to the list.
> Please turn on plain text email if you have the chance. It makes it easier
> to read on mobile devices and easier to reply inline).
>
> Aslak
>
> > We have a pretty rough around the edges working prototype, and we used
> > lambda’s to achieve the same look that users do in ruby. Then used
> > reflection to look through all classes in the assembly that derive from
> > keyword base.
>
> > public class StepTests : KeywordBase
>
> > {
>
> > public StepTests()
>
> > {
>
> > Given("^My Name is \"([^\"]*)\"$", (name) =>
>
> > {
>
> > throw new Exception("exception");
>
> > });
>
> > Given("^I live at \"([^\"]*)\"$", (location) =>
>
> > {
>
> > Console.WriteLine("Location is: " + location);
>
> > });
>
> > Given("^My city is \"([^\"]*)\" and my state is \"([^\"]*)\"$",
> > (city, state) =>
>
> > {
>
> > Console.WriteLine("City is: " + city);
>
> > Console.WriteLine("State is: " + state);
>
> > });
>
> > }
>
> > }
>
> > I think we can do something together for sure. Let me know what you think.
>
> > ~C hris
>
> > *Sent:* Friday, September 11, 2009 8:53 PM
> > *To:* Richard Lawrence
> > *Cc:* cu...@googlegroups.com; Anders Hammervold; Åsmund Eldhuset; Chris
> > Kooken
> > *Subject:* Re: Cucumber Wire Protocol and .NET (and Python)
>
> > 2009/9/12 Richard Lawrence <rich...@humanizingwork.com>
> > Step
> > > Definitions:
>
> >http://wiki.github.com/aslakhellesoy/cuke4duke/pure-java-step-definit....
aslak hellesoy
I agree on the lambda syntax, it is very concise and straightforward.
I am new to using github but will check out the repositories now.
This is very promising.
Richard Lawrence
tried both lambdas and attributes. (See
http://github.com/richardlawrence/Cuke4Nuke/blob/master/examples/WhatToPack/Steps.cs.)
We both preferred the lambdas for their similarity to Ruby. But when I
asked around for opinions, I found that non-Rubyist .NET devs
preferred the attributes. Since that's our target audience for the
project, I started there. I see no reason we can't support both at the
same time; they'd just be two ways to get step definitions into the
repository. If anyone does fork the project to add lambda support,
please consider doing it in a way that works alongside attribute-based
step definitions rather than as a replacement for them.
Thanks,
Richard
Matt Wynne
Hey Steven, thanks for the thoughts.
We did consider using a REST web service for this, but decided not to.
I'm not sure that .NET does have any lightweight web servers, at least
not as mature as something like Rack, which would mean the Cuke4Nuke
codebase would have to carry more layers with it. I do like the idea
of a web app just supporting a simple web API for listing and invoking
step definitions - it's something I've thought about several times,
and we could still end up building this at some stage, I think.
As we've build out the feature, it turns out we need to be able to
make calls in both directions (to support table diffing), which could
have got quite awkward with a strict client/server model so I'm
already glad we made the call to use the low-level protocol.
Thanks for the suggestions though :)
cheers,
Matt
Richard Lawrence
later today and tag ticket #1 as yours.
Regarding attributes vs. lambdas...See a few messages up the thread
where I explain why I recommend supporting both and implementing
attributes first despite us preferring lambdas. Short version: The
target audience for Cuke4Nuke is .NET devs who aren't comfortable with
Ruby. Those same people tend to be less comfortable with lambdas.
Attributes are more familiar in .NET. But I see no reason we can't
support both at the same time eventually.
Richard
2009/9/16 Åsmund Eldhuset <Asmund....@bekk.no>:
>> Greetings!
>>
>> I cloned Mr. Lawrence's repository a couple of days ago and tried to get it working with Mr. Wynne's cucumber version. Somehow, I never managed to get the rake build process to complete; it fails (in different ways) on both Windows XP and Ubuntu. Then, I realized that I didn't actually need cucumber in order to test it, so I started looking at the Visual Studio projects instead. However, I had problems running the tests (on Windows XP, using NUnit 2.5.1 (standalone, not through VisualStudio)) - any single test fixture would run, but when running both in sequence, the second one would fail with a SocketException saying "An existing connection was forcibly closed by the remote host". I might of course be doing something wrong, but it seems to me that the problem was due to the rather unfriendly way of killing the server in TestFixtureTearDown(). If this is indeed the case, I propose adding some kind of shutdown command to the protocol, along the lines in the attached diff file, which solved the problem for me - unless there are simpler ways to solve it or I simply am doing something wrong.
>>
>> I see from the WhatToPack example that you have been discussing two ways of defining the steps (attributes and lambdas). In the previous email, Mr. Kooken uses lambdas, but the TestStepDefinitions and Core projects seem to use attributes. What is the final decision?
>>
>> This seems to be an interesting project, so I would like to give ticket #1 ("Support for parameters on steps") a shot.
>
> (Now with bottom posting, apparently not supported very gracefully by my email client...)
>
> As per Aslak's request, I forked the repo and pushed my suggested change there instead: http://github.com/aasmundeldhuset/Cuke4Nuke/commit/67e12ce0e21c3f56be7f9edc450ae622deb9f73d
>
> --
> Åsmund Eldhuset
>
> ________________________________________
> From: Chris Kooken [chris....@gmail.com]
> Sent: Saturday, September 12, 2009 7:17 PM
> To: 'aslak hellesoy'; 'Richard Lawrence'
> Cc: cu...@googlegroups.com; Anders Hammervold; Åsmund Eldhuset
> Subject: RE: Cucumber Wire Protocol and .NET (and Python)
>
> We have a pretty rough around the edges working prototype, and we used lambda’s to achieve the same look that users do in ruby. Then used reflection to look through all classes in the assembly that derive from keyword base.
>
>
> public class StepTests : KeywordBase
> {
>
> public StepTests()
> {
> Given("^My Name is \"([^\"]*)\"$", (name) =>
> {
> throw new Exception("exception");
> });
>
> Given("^I live at \"([^\"]*)\"$", (location) =>
> {
> Console.WriteLine("Location is: " + location);
> });
>
> Given("^My city is \"([^\"]*)\" and my state is \"([^\"]*)\"$", (city, state) =>
> {
> Console.WriteLine("City is: " + city);
> Console.WriteLine("State is: " + state);
> });
> }
> }
>
> I think we can do something together for sure. Let me know what you think.
>
> ~C hris
>
> From: aslak hellesoy [mailto:aslak.h...@gmail.com]
> Sent: Friday, September 11, 2009 8:53 PM
> To: Richard Lawrence
> Cc: cu...@googlegroups.com; Anders Hammervold; Åsmund Eldhuset; Chris Kooken
> Subject: Re: Cucumber Wire Protocol and .NET (and Python)
>
>
> 2009/9/12 Richard Lawrence <ric...@humanizingwork.com<mailto:ric...@humanizingwork.com>>