Cucumber is a common tool used in many Rails applications to provide Acceptance/Integration testing. It uses a DSL called Gherkin which is a Business Readable DSL.
The idea is that you write the features of your application into Scenarios which are then executed by Cucumber. As a developer you also provide the steps to execute those Scenarios often using a tool like Capybara.
In the Rails community Cucumber can be slightly contraversial but I've come to believe that Cucumber is greatly misunderstood within the community.
@twe4ked I’ve come to really like Cucumber. I think it gets an unfair rap from a lot of devs.
— Leonard Garvey (@lgarvey) December 13, 2012
A really great conversation followed on Twitter, but I do often feel constrained by 140 characters.
Is love too strong a word?
I really like using Cucumber. Whenever I write a Feature I feel like I'm focused implementing that functionality, even if the very next thing I do is write a few specs for models and controllers. I feel that if I ever get sidetracked I can get right back into the flow by just running my Cuke.
It's for this reason that I completely agree with Chris Parsons when he says that Cucumber isn't a testing tool
A sales issue
Besides the whole web-steps awfulness, which is extremely well explained by Jonas Nicklas in his great post You're cuking it wrong, I think Cucumber has a sales problem.
@mwotton @lgarvey User stories are a great way to describe a system. Cucumber's problem is claiming that you can run them with little effort
— Warren Seen (@warren_s) December 13, 2012
- Understanding how to set it up as a newbie can be difficult. It isn't well described on the Cucumber website
- It promises a great deal: "The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid - all rolled into one format" The issue with this type of promise is that it doesn't seem to fit in with how most devs view the world. They have automated tests (written in Ruby!) so don't see the need for more wordy abstraction. They view the Features as something else to maintain in addition to tests and documentation.
- Cucumber is often sold as a way for Business people and devs to communicate. I'd argue instead that it's a way for devs and anyone else to communicate, you don't get benefit from Cucumber only if you can convince your Business Analyst to read your feature files. You should get benefit from Cucumber ever time you on-board a new developer, every time you need to remind yourself, or another dev, how a complex feature works (at least at a high level).
If Cucumber was instead pitched as a tool that helped you keep (and communicate) simple system requirements and your app in-sync then I think it would get more acceptance.