Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News BDD Tool Cucumber is Not a Testing Tool

BDD Tool Cucumber is Not a Testing Tool

Leia em Português

If you are using Cucumber just for automated testing you can do better. By writing scenarios that illustrate business rules instead of UI functionality you can get business analysts involved and writing scenarios before code enables programmers to be guided by an unambiguous specification. Then you are doing Behaviour-Driven Development (BDD) Aslak Hellesøy states reflecting over his experience of seeing it misused and misunderstood.

Hellesøy, who created Cucumber in 2008 with 5 million downloads during the first three years, emphasizes that Cucumber first and foremost is a collaboration tool aiming for a common understanding across all members of a team. Cucumber features should be written before the code implementing the feature. When you work with BDD writing examples, regression tests are a by-product, the testing is not the activity.

Looking at Cucumber for JavaScript, Julien Biezemans sees benefits in BDD coming to web development but notes that the same misunderstandings Hellesøy mentions leading to using Cucumber only as a testing tool are common here also. Also for Biezemans, BDD is about encouraging conversation between all involved, writing down examples to make things clearer and reduce ambiguity allowing everyone to agree on what they are building. Automating the scenarios resulting from the conversations is an optional next step.

Hellesøy declared last year that to use Cucumber you have to follow a process involving most people in a software team. That process is BDD which later was renamed by Gojko Adzic to Specification by Example. Somewhat simplified this process consists of two main activities:

  • Specification Workshops where business analysts responsible for the requirements together with programmers and testers discuss features to be developed, (these three roles are often called the three amigos). At the same time they write down examples of how the software should behave, as Cucumber scenarios.
  • Outside-In Development where programmers incrementally write code and run the scenarios using Cucumber until the feature passes all the tests. Programmers typically start with functionality closest to the user working their way inwards to core domain, hence the name of the activity.

Liz Keogh notes that defining BDD is hard; with a methodology derived from many other methods and philosophies she finds it difficult to draw a boundary on what is respectively is not included. Instead Keogh thinks of BDD as an anchor term, at its core are conversation, collaboration and scenarios together with ways to automate them. Around the core are a number of other practices like those mentioned by Hellesøy and many tools including Cucumber, JBehave and SpecFlow. Defining BDD Keogh therefore uses a phrase describing the anchor idea:

Using examples in conversation to illustrate behaviour

Rate this Article