[ANN] Introducing cucumber.js
Julien Biezemans
I'm excited to announce the birth of cucumber.js. It is the little
brother of our beloved testing tool, ready for any JavaScript
environment (i.e. browsers and Node.js).
It currently supports basic feature elements (features, scenarios,
steps). There are still a lot of things to implement like unknown step
definitions, scenario outlines, tags, tables, transforms, etc. It's
not to be considered stable, obviously :)
This is my first serious piece of JavaScript code. It's fully tested
with Jasmine and... cucumber.js ;) I welcome all the feedback you can
share!
https://github.com/jbpros/cucumber/tree/cucumber.js/js
Julien.
aslak hellesoy
> Hi everyone,
>
> I'm excited to announce the birth of cucumber.js. It is the little
> brother of our beloved testing tool, ready for any JavaScript
> environment (i.e. browsers and Node.js).
>
I'm really excited about this project - so excited that I have
endorsed Julien to use the name cucumber.js (I have previously
declined half a dozen offers to reuse the name in other language
ports).
One of the reasons I'm excited is because Javascript is fast becoming
a serious contender to Ruby and JVM languages, and so far there aren't
any high level BDD tools that I'm happy with. I know about Vows
(http://vowsjs.org/), but it's more of a steak
(https://github.com/cavalle/steak) kind of tool: Developer only since
it's all code and no text (gherkin).
I'm also excited because cucumber.js uses the same parser as
cucumber.rb: Gherkin. Last month I started releasing Javascript ports
of gherkin, which was relatively easy thanks to Ragel (the parser
generator). Here it is: http://search.npmjs.org/#/gherkin
> It currently supports basic feature elements (features, scenarios,
> steps). There are still a lot of things to implement like unknown step
> definitions, scenario outlines, tags, tables, transforms, etc. It's
> not to be considered stable, obviously :)
>
> This is my first serious piece of JavaScript code. It's fully tested
> with Jasmine and... cucumber.js ;) I welcome all the feedback you can
> share!
>
I took it for a spin, and it is so blazingly fast! And I can run it in
the browser! Of course there is a lot to do to bring it up to par with
cucumber.rb, but I hope the pull request will come in plenty. I for
one am going to try and integrate it with
https://github.com/cucumber/gherkin-editor so we can have a little
"try cuke" on the home page.
My first recommendation would be to split cucumber.js into several
files. Node.js has its own module system (exports) that don't work in
the browser. I suggest using require.js (http://requirejs.org/) which
works both on node and browsers. That would make the code a lot easier
to work with I think - especially as it grows.
> https://github.com/jbpros/cucumber/tree/cucumber.js/js
>
Great work Julien - I'm excited to see where this goes.
Aslak
> Julien.
>
> --
> 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 http://groups.google.com/group/cukes?hl=en.
>
>
Matt Wynne
On 27 May 2011, at 22:19, aslak hellesoy wrote:
> On Fri, May 27, 2011 at 10:00 PM, Julien Biezemans <j...@jbpros.com> wrote:
>> Hi everyone,
>>
>> I'm excited to announce the birth of cucumber.js. It is the little
>> brother of our beloved testing tool, ready for any JavaScript
>> environment (i.e. browsers and Node.js).
Very cool. Thanks taking the initiative on this Julien.
Would it be crazy to try and get a single set of features that pass on both cucumber.rb and cucumber.js?
>
>> https://github.com/jbpros/cucumber/tree/cucumber.js/js
>>
>
> Great work Julien - I'm excited to see where this goes.
>
> Aslak
>
>> Julien.
>>
>> --
>> 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 http://groups.google.com/group/cukes?hl=en.
>>
>>
>
> --
> 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 http://groups.google.com/group/cukes?hl=en.
>
cheers,
Matt
ma...@mattwynne.net
07974 430184
aslak hellesoy
Julien and I have talked about that. The tricky part is features that
include stepdef code (most of them):
https://github.com/cucumber/cucumber/blob/master/features/background.feature#L148
I guess we could just add "And a file named
"features/step_definitions/***" with:"
for each language.
Where to store them is another question. Do we need a
cucumber-features project that we submodule into the various
implementations?
Aslak
Julien Biezemans
to read those after several weeks of work in my stash. ;)
My motivations for contributing on a JS port of Cucumber are similar
to Aslak's. I started working on a Continuous Integration tool for
Node.js and I was missing those high-level domain-centric acceptance
tests (a.k.a. "features") I'm used to work with. It just didn't feel
right to me. Aslak releasing Gherkin on JavaScript and some boosting
discussions with him were the triggering factors for me to start
hacking.
Now on cucumber.js itself:
I'm not happy with its current monolithic state. I initially wanted
modules. But after a while I decided to put everything in one big file
in order to ease feature execution within browsers. Since then I read
more about libs like requirejs and it is definitely the way to go to
get a cleaner code organization.
Cucumber.js has only one basic feature that drove the development of
the first commit. From the beginning I wish I could use Ruby's
features to have a common test suite. That would be nice and powerful
in terms of consistency. From that perspective, I really like the idea
of a "features" project that would be referenced in "implementation"
projects (java too? :)).
I can't wait to see some features edited in the Gherkin editor and
executed right next to it on the same page. This opens so many doors.
Oh and BTW, cucumber.js has a new home (already) and is now
independent from the ruby project:
https://github.com/cucumber/cucumber-js
I can't say this enough: don't hesitate to give feedback :)
Thanks again for your support!
Cheers,
Julien.
--
Julien Biezemans - j...@jbpros.com
JBpro's Interactive - http://www.jbpros.com/
+32 495 60 32 79
Joseph Wilk
> Hi everyone,
>
> I'm excited to announce the birth of cucumber.js. It is the little
> brother of our beloved testing tool, ready for any JavaScript
> environment (i.e. browsers and Node.js).
>
> It currently supports basic feature elements (features, scenarios,
> steps). There are still a lot of things to implement like unknown step
> definitions, scenario outlines, tags, tables, transforms, etc. It's
> not to be considered stable, obviously :)
>
> This is my first serious piece of JavaScript code. It's fully tested
> with Jasmine and... cucumber.js ;) I welcome all the feedback you can
Thanks for you hard work Julien, look forward to trying it out!
--
Joseph Wilk
http://blog.josephwilk.net
http://www.limited-red.com
http://www.songkick.com
+44 (0)7812 816431
> share!
>
> https://github.com/jbpros/cucumber/tree/cucumber.js/js
>
> Julien.
>
Mike Sassak
Very cool Julien! I can't wait to see all the crazy mashups this makes
possible. :-)
Mike
Matt Wynne
Wow, that is a very complicated feature!
I personally would prefer if we could try to make these features much more declarative anyway, I think it would make them easier to read, less brittle, and possibly easier to understand when they fail, too. The one drawback is that they might not act so well as examples of how to use Cucumber, but is that as important?
I don't have time to wrap my head around that specific feature right now, but I think it's a worthwhile challenge to see if we can push the implementation details down into step definitions so that the Gherkin features are language-agnostic. I'm up for helping with this.
> Where to store them is another question. Do we need a
> cucumber-features project that we submodule into the various
> implementations?
Yes, I guess that would work. We'll probably want a way to run core features (shared by all languages) and additional ones that are specific to the platform, since each implementation is bound to have unique features, and we'll have to keep the core small and grow it as cucumber.js grows.
cheers,
Matt
--
Freelance programmer & coach
Founder, http://relishapp.com
+44(0)7974430184 | http://twitter.com/mattwynne
Julien Biezemans
On Sat, May 28, 2011 at 8:06 PM, Matt Wynne <ma...@mattwynne.net> wrote:
>
> Wow, that is a very complicated feature!
>
> I personally would prefer if we could try to make these features much more declarative anyway, I think it would make them easier to read, less brittle, and possibly easier to understand when they fail, too. The one drawback is that they might not act so well as examples of how to use Cucumber, but is that as important?
>
> I don't have time to wrap my head around that specific feature right now, but I think it's a worthwhile challenge to see if we can push the implementation details down into step definitions so that the Gherkin features are language-agnostic. I'm up for helping with this.
I agree, aiming at a higher level of abstraction in (some) cucumber
features would be great. I'm not so comfortable with those big
multiline steps containing "code". However, I'm a bit concerned that
it will be challenging to end up with a fairly limited set of reusable
step definitions and not a big collection of "non-recyclable" step
defs.
I guess the best thing to do now is to try converting a few existing
features. We'll see where it leads us.
Julien.
Julien Biezemans
I wrote a feature prior to fixing issue #1. I took this opportunity to
try moving implementation details down to the step definitions.
Here is the result:
https://github.com/cucumber/cucumber-js/blob/205b4e074d091b162ef1a49a649d954e913929f6/features/issue001-async_stepdef_callbacks.feature
https://github.com/cucumber/cucumber-js/blob/205b4e074d091b162ef1a49a649d954e913929f6/features/step_definitions/cucumber_steps.js#L33
The "When" and "Then" steps would probably be good candidates for reuse.
Note that this is not a perfect example in terms of implementation
independence; asynchronous step definitions might not apply to all
languages. i.e. this feature might not be common to all "cucumbers".
But that's not really my point here.
What do you think of it?
Julien.
Julien Biezemans
I've tried to write "better" features while working on cucumber.js
today. I tested different levels of abstraction. Here is a summary of
my experiments:
https://gist.github.com/999006
Any thoughts?
Cheers,
Julien.
Richard Lawrence
Thanks for making the alternatives concrete.
Personally, I like #1, the language-specific option, for most of the features in Cuke4Nuke. I want the features to express how I expect the tool to be used.
That said, I would love to also have a set of features that should work for every Cucumber implementation independent of language (like RubySpec does for Ruby implementations). I'd prefer these to look like #2—a concrete, visible example of the Gherkin with the specific language step definitions hidden.
Richard
> Cheers,