> 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-f

> 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.