Julien Biezemans is a Cucumber core team member and the author of Cucumber.js. Cucumber.js is a native JavaScript implementation of Cucumber, and is a strict port that can run on any JavaScript environment.
Running on Node.js as well as within any browsers, Cucumber.js is virtually serviceable against everything producing JavaScript and HTML (Node.js, Ruby on Rails, PHP, .NET, etc)
InfoQ: What is Cucumber.js? Why should somebody care about it, what problems does it solve?
Biezemans: Cucumber.js is the JavaScript port of the well-known Behaviour-driven development (BDD) tool called Cucumber, initially written in Ruby by Aslak Hellesøy. There are several Cucumber implementations nowadays, including Ruby, the JVM, .NET, PHP, C++, and more.
Cucumber is an automation tool that is able to translate specifications (mostly concerning software development) written in human languages, like English or French, into some code computers can understand such as JavaScript, Ruby, or Java. That code then drives any sort of software that can be automated. It has become a popular solution for web application automation, but has been used in other various fields, like native mobile app development, embedded systems, and even hardware testing.
BDD is an agile methodology that was developed by Dan North based on test-driven development. It promotes communication, conversations and close collaboration between everyone involved in a project. One of the underlying objectives of BDD is to bridge that well-known gap between business and technology. Often, people from those two worlds don't understand each other well.
The idea of writing scenarios (or "examples") in a natural language is one approach to solving that communication issue. Those specifications are produced and used as a reference during discussions between the stakeholders, with a shared vocabulary. They're also used to drive the actual development of the system: the developers will automate them before implementing the described features of the system; they become tests that can literally drive the coding process. And finally, they're used in the long-term as both living documentation and regression tests.
InfoQ: Please can you tell me about some of the use cases for Cucumber.js?
Biezemans: As for most of the Cucumber flavours, the obvious use case of Cucumber.js is web automation. It is written on top of the Node.js stack but is able to run on any JavaScript environment (think browsers!). That's the interesting bit about Cucumber.js, compared to the other implementations: it can be used on a broader range of environments. JavaScript is sort of the ubiquitous language nowadays, it's obviously available in all browsers but also on servers, thanks to technologies like Node.js and the JVM. I know there are teams automating web apps built with various technologies like Node.js, Angular.js, Backbone, PHP, Java, Ruby, and Rails, to name a few.
That being said, there are other interesting uses of Cucumber.js. It is particularly efficient and pleasant to interact with network resources (e.g. with HTTP) with Node.js. That's why it's pretty easy and common to test HTTP APIs with Cucumber.js combined to some network-aware assertion libraries (the backend does not have to be JavaScript-backed). That's one thing I'd like to insist on: Cucumber doesn't know anything about the web, HTTP, networks or CLIs. It's there to translate some natural language specifications into runnable computer code. Whatever you hook to that code is none of Cucumber's business.
Cucumber.js can be also be used to automate command-line interface applications (a good example is Cucumber.js that has got its own test suite it runs against itself on the CLI).
InfoQ: Can you describe for me some kind of problems that are a better fit for one tool than another? In what circumstances would someone use Cucumber.js, and when would they be better suited to using something else?
Biezemans: There are many JavaScript TDD/BDD and other testing tools out there; some of which are really good. Cucumber (Ruby) suffered a hype wave a few years ago: everybody jumped on it, thinking it was the silver bullet. However, in many cases, it didn't make much sense to add the extra layer imposed by Cucumber (i.e. the specifications written in a plain natural language).
The conversations between the developers and the rest of the stakeholders at that time were nonexistent, so there were no needs for scenarios written in English and it just got in the way of the coders, increasing the cost of maintenance for no good reason.
This still happens today. It's a well-known fact that we -- technical people -- tend to be attracted to new shiny tools and start questioning their true relevance only after we've hit our thumbs a few too many times with the tool. My main advice to anyone considering Cucumber would be to ask themselves the following questions: "Will the team (everyone, not only the tech people) benefit from scenarios written in plain English? Is there a chance it'll help someone understand things better and communicate more efficiently?" If the answer is yes, then Cucumber might be the right tool for the job.
Don't get me wrong, though, I've seen successful teams using Cucumber only on the "tech side of things". I think the reason is that scenarios help people step away from the technical concerns and have deeper thoughts about the expectations in terms of capabilities and behaviours of the system they're building.
InfoQ: Tell me about the Cucumber.js community? Do you get community volunteers contributing, and can InfoQ readers contribute?
Biezemans: Cucumber.js is almost three years old, and the community is growing. It's on a smaller scale, similar to what's happening to the Node.js community: there are people coming from very different places. There are developers and testers coming from various communities just because of the omnipresence of JavaScript. I find it really enriching because you get the chance to share new experiences and ideas regarding similar problems sometimes solved very differently than what we're used to. Diversity is good!
The opposite is also true, JavaScript is a good vector for spreading what we think are effective principles and practices (i.e. BDD!) to communities we had no connections with before.
There are regular contributions and we've got some very supportive people. We're in the process of bringing all the Cucumber "sub-communities" together. That was actually the theme for this year's CukeUp! conference: one big happy BDD family. We really don't want to see the community fragment into specific technologies, that's why there's only one Cucumber mailing list. Support for Cucumber.js is being added to popular IDEs like Jetbrains Webstorm 8 and Visual Studio. I see that as a good sign regarding adoption of the tool.
Anyone willing to contribute can visit Cucumber.js GitHub repo to check out the pending issues and send pull requests.
InfoQ: What are you working on for the next major release (would that be 0.4.5?) and when is going to be?
Biezemans: There's a demand for a plugin system. Attaching result formatters and other listeners to Cucumber.js is currently possible, but has two drawbacks:
You have to deal with some of the internal objects
The CLI argument parser is not flexible enough to let you specify plugin-related options when invoking Cucumber.js from your terminal.
The objective is to make Cucumber.js more modular, and let people publish simple plugins to repositories like NPM and Bower. A plugin API will probably make us release 0.5, and we'll most certainly rely on that API to add support for Cucumber Pro, the collaboration platform we're working on at Cucumber Ltd.
There's an interesting pull request for parallel runs that should be merged pretty soon.
I'd like to revisit the packaging system we use for the web. As I said earlier, Cucumber.js is built with Node.js. To make it run on the browser, it has to be bundled. The current code for that is pretty obscure, based on an archaic version of Browserify and is not tested.
And as with any projects, there are some issues, mostly regarding JavaScript callbacks and hooks that must be fixed.
InfoQ: What are the plans for the longer term plans for Cucumber.js?
Biezemans: Once we have a better web packaging system, I'd like to make Cucumber.js more visible to the browser-only scene; it's already possible to run it on a browser, but not straightforward. It's a shame because I think there's a whole "market" there, especially with the rise of frameworks like Angular.js and Ember.js.
As mentioned before, the documentation could be improved. It would be useful, especially for newcomers, to have access to more examples, tutorials and demonstrations of how to use Cucumber.js in various environments.
There are a few missing ancillary features (details available in the development status table on the README) compared to the other Cucumber flavours. These should be implemented before we release 1.0.
InfoQ: Other than your work on Cucumber.js, and BDD in general, tell me about something you have a passion for?
Biezemans: I'm highly interested in service-oriented architectures, event sourcing, and domain-driven design. I've been building systems based on those concepts and patterns for quite a few years now. I've open sourced an experimental Node.js library, called Plutonium, for DDD/Event Sourcing and I would like to give it more love in the future.
I'm a designer wannabe (and learning!).
Computers aside, I love spending time with my family. My kids are such a source of joy and discovery. I dig science in general and I am particularly interested in physics and cosmology. Oh, I can't live without music in my ears, but it's been a long time since I played the guitar myself.
