Announcing cucumber-electron

Pretty soon no word will have its original meaning. An electron is not a subatomic particle. A cucumber isn't a veggie. Rust isn't...

Can anyone explain why you would want to use Cucumber? I heard it enables non-programmers to write the tests themselves but I don't see that as realistic as non-programmers don't have the training to specify requirements rigourously. At least with coded tests you can use IDEs to validate and refactor your tests.

For me so far the most pleasant to work with has (contrary to its name) been Nightmare (http://www.nightmarejs.org/), which is a Node.js library that drives Electron. It has a really pleasant API and its developers claim that it is faster than PhantomJS. Unlike PhantomJS, however, it is not truly headless; it needs an X server like xvfb to run.

We use cucumber at work for a few weeks now. Our product owner actually writes the initial feature files for our end-to-end tests and we refine them. We keep sending him back on what we changed and why, and the product owner learns from that and tries to do it the next time. We started doing this around 6 weeks ago and it is helping us developers a lot in my opinion, as well as getting some work off of us. Sure, we need to refine the POs feature definitions, but it's better than nothing.

I can tell you why I'm using it, and it's not to enable non-programmers to write tests. (Not anymore, it was at first...)

The number one advantage is that using Cucumber produces human-readable documentation that is also executable, and through the magic of CI is prevented from becoming stale.

I use Cucumber with Rails, and I've actually heard a lot of really good arguments not to use Cucumber. The one thing these all seem to have in common is, they almost universally do NOT completely rebuke TDD at-large. Nobody (competent) is suggesting you should develop by the seat of your pants. They have issues with Gherkin or with Cucumber's implementation specifically, but if your team had success with Cucumber, you would not give it up without planning to have a replacement.

You may choose to eschew Gherkin style entirely, and you can certainly accomplish much the same thing using feature testing in modern RSpec and scenarios. This may be easier to refactor for you, but for me a well-organized vocabulary of step definitions makes it so easy to copy a scenario, reorganize the steps, and add some new things to create a new feature, adding almost no new test code.

There is also Spinach, which rips out all of Cucumber's regex silliness and declines to enforce a global vocabulary, instead encouraging modular design of scenarios and step definitions (since you might want to say the same thing in two different places and mean two different things.)

There is also Turnip, which integrates Gherkin into RSpec and also has many of the same advantages of Spinach, but includes other options (cleaner options) besides the Regex method for building parameterized step definitions. I think this one is my favorite, but my small project still uses Cucumber proper.

In the beginning of our project, it was very helpful that my PM was writing out requirements in Cucumber style. It meant that while someone (not a coder, but not an inexperienced PM either) had gone to the trouble to specify requirements with rigor, I could focus on coding, just jump in and start writing features, with a clear target of limited scope, that I could easily follow to avoid straying off into the weeds.

Before long my PM got busy with other projects and I took over writing the cucumber stories. Not just me, but the other dev too -- and that was just as well. I often found myself rewriting PM's scenarios anyway, to make them easier to map directly to step definitions, more clear in a context-free sense, or generally less ambiguously specified. These enhancements also made them less human-friendly.

Both approaches to writing Cucumber stories definitely have merit. The one thing you need to have is a strong set of test scenarios (however you've implemented them) with good total coverage of the features and the requirements, so that new or changed requirements can be evaluated in the context of the whole program: what features are broken by your change?

Two things I have found are also critical when using ATDD: your whole team (at least all of the devs) need to be able to run the tests, and (maybe even more important) you need to have a CI solution in place so that no individual needs to be responsible for running all of the tests after each change when your suite gets too heavy for a pre-commit hook. A regression suite is like a pager: when nobody is on-call then everybody is on-call.