Aslak’s view of BDD, Cucumber and automated testing

This is a quote from Aslak Hellesoy on the Cukes Google group.

“Even on this list, the majority of people seem to think that Cucumber == Automated Tests == BDD, which is WRONG.

What people need to understand is:

Cucumber is a tool for BDD
Cucumber is a tool for Specification By Example
Specification By Example is just a better name for BDD
Specification By Example / BDD means examples (Scenarios) are written *before* implementation
Specification By Example should happen iteratively, in collaboration with non-technical stakeholders
Automated Tests are a by-product of Specification By Example
Writing Automated Tests does *not* imply you’re doing Specification By Example
Using Cucumber for Automated Tests without doing Specification By Example is stupid
Cucumber is not a tool for Automated Testing, it’s a tool for Collaborative, Executable Specifications”

Aslak Hellesoy    – 12th December 2013
Cukes Google Group!topic/cukes/XFB7CjWuI14

By |December 14th, 2013|Agile, Cucumber|0 Comments

Living documentation can be readable and fast

In an earlier blog I promised to describe how we could exercise thin slices of our application stack, while still expressing our scenarios in a business-readable, end-to-end style. I talked about this at Cuke Up! last week and published an article covering it in the ACCU journal Overload. For completeness, I’m now adding this as a blog entry too.

Let’s assume we have the example scenario below, taken from Matt Wynne’s Squeaker example, that deals with registering at some website. (This is written in Gherkin and will be executed by Cucumber.)
Feature: Sign Up
Scenario: New user redirected to their own page
  When I sign up for a new account
  Then I should be taken to my feeds page
  And I should see a greeting message
Each line in the scenario causes a corresponding ‘step definition’ to be executed. How you implement the step definitions is up to you, and depends on the nature of your system. The example above might:

fire up a browser, navigate to the relevant URL, enter specific data, click the submit button and check the contents of the page that the browser is redirected to
call a method on a Registration object and check that the expected event is fired, with the correct textual payload
or anything else that make sense (e.g. using smart card authentication or retina scanning)

The point is that the text in the example describes the behaviour, while the step definitions (the glue code) specify how to exercise the system. An example glue method would be:
@When(“I sign up for a new account”)
public void I_sign_up_for_new_account() {
// Do whatever it takes to sign up for a new account
// e.g. exercise the web UI using Selenium WebDriver
Newcomers to this style of working often adopt […]

By |April 6th, 2013|Uncategorized|6 Comments