11–20 of 48 posts
> Saving Agile with BDD and Cucumber First value of Agile Manifesto: "Individuals and interactions over processes and tools "
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 one writing or maintaining the tests. You just have to have a DSL that the test maintainers can use, and they handle writing and maintaining. But thats it.
If the devs are the ones who have to write the tests, as is far more common; then interfacing with capybara directly is much much better than bringing cucumber into the mix. I used to be into cucumber, but once i switched over to a leaner approach i found testing was much easier and more enjoyable.
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 " rel="nofollow">https://github.com/jnicklas/turnip>, or Spinach " rel="nofollow">https://github.com/codegram/spinach>, or even Steak " rel="nofollow">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.
Most of the time I've spent with Cucumber in actual work projects has been wasted on trying to write steps to wrap idiosyncratic UI patterns which aren't handled out of the box - of course its been years since then and the UI on that project was particularly horrendous. That being said, I do find a lot of value in being able to translate text from a story - "As a user I should see " directly into a test.
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…
It looks like it's limited to testing web sites and is not really useful for me. Gherkins can be adapted for all kind of tests (even if I agree that it's far from perfect).
vow what a Joke! I guess this Cucumber guy has nothing else in his life to do. He talks about how testers and developers should interact as a solution to fix the Agile process which sucks anyway no matter what. so developers need to worry about the stupid tests that they need to pass which are created by the testers. Testers are way less qualified than developers in most companies obviously there are exceptions here…
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.
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.
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?