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.
/filters:no_upscale()/sponsorship/topic/2c0d72d2-1768-47c2-8f5b-24f3ef0ae0e0/QconNYrsb-1679560094156.png)
/articles/BDD-sleep-disorders/en/smallimage/logo-1671602700685.jpg){kind=logo}
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
/presentations/devsusops/en/smallimage/adrian-cockcroft-small-1684908390875.jpg)
/articles/gdpr-with-spring-and-aop/en/smallimage/easy-implementation-of-GDPR-with-aspect-oriented-programming-small-1684505109873.jpg)
/articles/software-delivery-performance-indicators/en/smallimage/software-delivery-performance-indicators-at-different-granularities-small-1684312207072.jpg)
/articles/api-design-review/en/smallimage/API-design-reviews-are-dead-long-live-API-design-reviews-small-1684310900854.jpg)
/presentations/dark-energy-matter-microservices/en/smallimage/chris-richardson-small-1684240727275.jpg)
/presentations/techno-solutionism-ethics/en/smallimage/katharine-jarmul-small-1684239823523.jpg)
/articles/learning-ebpf-observability/en/smallimage/learning-eBPF-for-better-observability-small-1684247266792.jpg)
![[R]Evolutionize Your Retrospectives with Active Sensemaking](https://imgopt.infoq.com/fit-in/50x50/filters:quality(80)/articles/retrospectives-active-sensemaking/en/smallimage/revolutionize-your-retrospectives-with-active-sensemaking-small-1684227204199.jpg)
/articles/rust-ecosystem-review-2023/en/smallimage/Rust-reviewed-the-current-trends-and-pitfalls-of-the-ecosystem-small-1684148505661.jpg)
/articles/devex-metrics-framework/en/smallimage/DevEx-a-New-Metrics-Framework-small-1683887713694.jpg)
Community comments
Welcome Critique
by Aslak Hellesøy,
The problem is the fleshy bit at the keyboard
by Ethar Alali,
Welcome Critique
by Aslak Hellesøy,
Your message is awaiting moderation. Thank you for participating in the discussion.
As the author of Cucumber, I welcome the critique of Cucumber - or rather - the way it is often (mis)used.
When Cucumber is used exclusively as a testing tool without involving product owners and business analysts it can be hard to justify the extra overhead it carries.
Another way I often see it misused is to use it as a lower level testing tool where an xUnit tool would be more appropriate. This is a direct consequence of failing to involve non-technical people.
This is why we will soon be releasing Cucumber Pro [1] - a collaboration platform for Cucumber. We hope that Cucumber Pro will help bringing non-technical stakeholders into the process, encouraging the workflow we intended from the beginning.
Also see the announcement of Cucumber Pro here on InfoQ [2].
[1] cucumber.pro/
[2] www.infoq.com/news/2013/09/cucumber-pro
The problem is the fleshy bit at the keyboard
by Ethar Alali,
Your message is awaiting moderation. Thank you for participating in the discussion.
This is actually a much bigger problem, but not one of tooling, but understanding the purpose and scope of them. For me, there is nothing wrong with cucumber and BDD platforms as a whole. Regardless of whether you apply BDD, TDD, OCL, VDM, Spec# or any other testing technique, the main thing it has to have is the principle of a context, with pre and post conditions. After all, a system of any type is composed of only two things. An action (When) and an initial condition (Given). The post-condition (a Gherkin 'Then') tests that the conditions expected at the end of the action hold. In deterministic systems, this is true regardless of whether the system is IT, business or even evolution (where fitness funcitons can be identified) and it applies at all level of scale. Hence, TDD for white box, BDD for black-box.
The problem is the organic matter that sits behind the keyboard who more often than not unfortunately doesn't understand the key usage and trade offs of using one framework or technique over another (e.g. when SpecFlow becomes too heavy and adds zero value for the COST of putting it into your project - which may not be a lot, but add this up over all devs in the team and the build process/CI and metrics and you suddenly have work done to yield zero value)
That said, a lot of what has been touted as benefits of say, SpecFlow, do not actually manifest. For example, SpecFlow is often mistakenly touted as side effect less. This is a complete misnomer as since C# or VB.NET supports side effects, the use of SpecFlow in those environments automatically means the whole structure supports side-effects, even if the Gherkin does not.
What it does do is add value to the conversations that can occur, pure and simple and that's it. This has the indirect advantage of making it easier for product owners and 'business people' to participate in the feature definition process from the outset, without an explicit analyst necessarily being required to translate (and being fleshy, introduce the risk of an error of communication as another 'moving part' if the trade-off isn't beneficial enough). The trade-off/overhead is the amount of learning required to pick up a platform, the market risks of people knowing it (unless it is already mainstream), the extra a company will have to pay for the more obscure skill-sets etc. Without that understanding the true worth of a tool isn't fully understood. Plus, this doesn't stay the same with time. The more mainstream ad popular a tool, the less the risks and costs of finding staff who know it.