InfoQ: What is Cucumber.js? Why should somebody care about it, what problems does it solve?
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?
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?
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?
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.
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.
Mike Amundsen May 29, 2015
Ben Linders May 28, 2015