21–30 of 48 posts
> Saving Agile with BDD and Cucumber First value of Agile Manifesto: "Individuals and interactions over processes and tools "
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 specifica…
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.
Earlier quoted context omitted.
The myths of having non-developers read tests have been dispelled for years. I'm not even going there.
That's too broad a claim. Why are non-developers in your organization not willing/able to read test cases?
It's just a special case of the general problem with tools that aim to be easy for non-programmers to use while doing the same things as programming languages. It's always a leaky abstraction.
> Saving Agile with BDD and Cucumber First value of Agile Manifesto: "Individuals and interactions over processes and tools "
> "Individuals and interactions over processes and tools"
Right. That means processes and tools should serve individuals by supporting their interactions, rather than individuals and their interactions being reformed to fit preconceived processes and tools. That doesn't mean that processes and tools are irrelevant, or that sharing experiences and ideas about how particular processes and tools can serve individuals in their interactions is contrary to Agile.
(In terms of promotion of processes and tools, it really has nothing directly to do with whether or even how those things should be promoted: it does have a lot to do with how -- and who on -- teams should evaluate processes and tools that are being promoted, though.)
Earlier quoted context omitted.
One of the nice things about BDD tests in Cucumber/Gherkin is that they're written down in plain text (English), a language that managers, testers, and developers all presumably speak. The Gherkin language is actually very useful for facilitating communication/interactions.
The myths of having non-developers read tests have been dispelled for years. I'm not even going there.
I've found it very useful, where there's ambiguity about how a particular feature works, to write a Gherkin spec that describes it. It's easy to understand, and can be agreed upon or even edited by my colleagues who aren't developers, but remain part of a CI process.
YMMV, but this remains one of the lazier dismissals of BDD.
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 specifica…
cucumber? what is this, 2013? rspec + capybara is much more enjoyable and maintainable. Maintaining a cucumber test suit is basically a nightmare. I hate writing tests for it, I hate fixing tests in it when they break, and i hate the random cucumber exceptions that cause random failures. and should you come to a point where you want to optimize the test suit performance, good luck! cucumber is good if you're not the…
If you're using it to communicate features to other team members, it can be super-useful, since it's much easier to comprehend that the equivalent developer-friendly code.
cucumber? what is this, 2013? rspec + capybara is much more enjoyable and maintainable. Maintaining a cucumber test suit is basically a nightmare. I hate writing tests for it, I hate fixing tests in it when they break, and i hate the random cucumber exceptions that cause random failures. and should you come to a point where you want to optimize the test suit performance, good luck! cucumber is good if you're not the…
Earlier quoted context omitted.
One of the nice things about BDD tests in Cucumber/Gherkin is that they're written down in plain text (English), a language that managers, testers, and developers all presumably speak. The Gherkin language is actually very useful for facilitating communication/interactions.
The myths of having non-developers read tests have been dispelled for years. I'm not even going there.