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
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
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.
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
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
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.
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 :)
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.
2009/9/16 Åsmund Eldhuset <Asmund....@bekk.no>:
>> 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)