BT

Your opinion matters! Please fill in the InfoQ Survey!

BDD Tool Cucumber is Not a Testing Tool

| by Jan Stenberg Follow 9 Followers on Mar 29, 2015. Estimated reading time: 2 minutes |

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

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT