4 ms·
The biggest gain of Cucumber I have seen is executable specifications. That is, every development task is described somewhere, whether it's pages and pages of a
by dankohn1 11y ago
The biggest gain of Cucumber I have seen is executable specifications. That is, every development task is described somewhere, whether it's pages and pages of a Google Doc or a couple lines in a Github issue. Code then gets implemented, and is almost certainly iterated over time. The question is, does the specification ever get updated to match the code's behavior?
With Cucumber, you have a relatively clear specification (written in Gherkin's Given-When-Then syntax), and it always remains up-to-date because the developer needs to update it as corner cases or new scenarios arise. (Of course, this assumes you are running continuous integration with something like CircleCI and tracking code coverage with something like Coveralls.io.)
I don't think there's anything magic about Cucumber, vs. Turnip <https://github.com/jnicklas/turnip> https://github.com/jnicklas/turnip>, or Spinach <https://github.com/codegram/spinach> https://github.com/codegram/spinach>, or even Steak <https://github.com/cavalle/steak> https://github.com/cavalle/steak>. But I do think the Gherkin syntax encourages use of clear descriptions that make it easier for a new developer (or yourself, 6 months later) to understand what a feature is supposed to do, and in particular, to avoid accidentally breaking it as you make other changes.
- _csoo 11y agoI found this to be the case when writing a Cucumber test for an Emacs package. You can see an example here: https://github.com/omouse/org-doing/blob/master/features/org-doing.feature https://github.com/omouse/org-doing/blob/master/features/org... It was more helpful to write "Given I have an non-existent file" than to write "(not (file-exists-p org-doing-file))". One can be read by others who don't understand Emacs-Lisp and they'll understand the concept, while the latter can only be read by Emacs-Lisp developers. With the Gherkin syntax I'm free to move my tests over to another text editor and implement code that's specific to the text editor. For example, I could use my tests to implement the package for VIM or Atom (something I might do on a weekend). The best part is that you have the spec under version control and locked down instead of spread across. At work no one is really updating the functional spec of our project and it means we have information that's falling through the cracks and is in separate emails or IMs. Executable version-controlled specs have to be maintained but at least they're in one spot.
- sanderjd 11y agoAlso somewhere on this continuum between gherkin and rspec: rspec-given[0]. Keeps Given-When-Then, but ditches the feature / step file split. [0]: https://github.com/rspec-given/rspec-given https://github.com/rspec-given/rspec-given