The Behaviour Driven Development, BDD, tool Cucumber has been popular in Ruby's TDD community for a while now. It offers a way to write tests that anybody can understand, regardless of their technical knowledge. This is all good, but is any of the benefits of Cucumber really that beneficial, Kevin Liddle asks in a case against Cucumber.
In theory Cucumber can be a bridge between developers and managers, but Kevin experience is that it's never used that way. Non-technical people don't read code; they care about use cases and using the application.
Kevin's use of Cucumber is not for testing but for gathering of feature requirements. He has found that the Gherkin syntax provides a very clear and concise way of explaining a feature.
Kevin's advice is to stop writing Cucumber tests unless there really is someone reading them and who would not understand pure Ruby.
In a response, Jon Frisby writes about his view on Cucumber. He finds the real value in capturing the intent of a feature and notes that there is a subtle difference compared to Kevin's gathering of feature requirements.
Jon describes requirements as a moment-in-time snapshot, a means of communicating an objective between people in a project. They are only meaningful in terms of the context of that moment. In contrast, Jon sees intentions as a more context-free way of expressing an objective. He finds them less useful for communicating what needs to be built, but they fill a gap that requirements have, in maintenance of a system. Jon exemplifies with a scenario where you're implementing a feature and while doing so, a test breaks. When properly written, in a Cucumber-As-Intent-Specification way, the test will tell you what the high-level intent of the feature is. This generally makes it quite easy to comprehend why the test was broken and how to fix it. In his article, Jon gives some examples of features he thinks describes the intent in a good way.
Matt Polito, also in a reaction to Kevin, has written about his view which briefly is that Cucumber makes it possible to describe the intended behaviour of applications in plain English, instead of relying on the code base as the only source for describing this behaviour.
Cucumber is an open source tool for BDD currently for nine programming languages, including Ruby, JVM-based languages and JavaScript.
.NET languages are supported through the SpecFlow project.
