3 ms·
You're right, in that if you are writing Gherkin specs as a replacement for something you can implement using Capybara, then I don't think you'll get the most o
by matthewmacleod 11y ago
You're right, in that if you are writing Gherkin specs as a replacement for something you can implement using Capybara, then I don't think you'll get the most out of Cucumber – it becomes an unnecessary abstraction.
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.
- meesterdude 11y ago> 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. In ruby/rspec it's actually still understandable and direct. in other languages, maybe not so much. I have not run into a cucumber implementation I liked. I agree it can lead to a human readable spec, but the effort it takes to get there, and stay there, is a nontrivial cost in terms of maintenance/flow/optimization. I don't think it solves technical problems, but organizational. It's all about tradeoffs, with everything we do. Outside of someone else writing and maintaining the spec, I don't think the downfalls at all warrant any benefit of clarity. cucumber is not "free" to use, it's a commitment with lots of fine print. I suppose thats really what i'm trying to advocate, in the end. At least thats been my experience across 5 or so projects with it. YMMV.