by Degree Admin

Introducing Cucumber


A large part of developing a successful IT application is ensuring the customers demands are met, and minimizing bugs as the system goes live. A good place to start is using an agile development strategy, with heavy customer involvement throughout the development cycle. For those who wish to learn more about agile development I would recommend reading “Agile Software Development: Principles, Patterns and Practices” by Robert C. Martin and “Agile Estimating and Planning” by Mike Cohn. Both are excellent books.

Some may have the belief agile development removes the necessity of documenting the system. This could not be further away from the truth. The principal behind agile is to plan as little as possible up front, and plan and document your system as you go. A good way to plan and document is by using User Stories. A User Story usually follow the “As a, I want, So that” pattern.
As a Blog writer
I want to preview my post
So that I can proofread my post before posting it.

Each User Story has several acceptance criteria which defines when a User Story is to be considered feature complete. Each acceptance criteria is written in a “Given, When, Then” grammar. One criteria for each case to test.
Given I have written a post
When I navigate to the preview
Then I want to see my post as it would be shown in the blog

Given I have navigated to the preview
When I use the cancel function
Then I want to return to edit mode

An user story is considered complete when all of its acceptance criteria are met and accepted.

When developing a small system with few stories, this is manageable. But as the project increases in size, ensuring that a user story is met, and ensuring nothing breaks as the development continues gets increasingly difficult. Having a large dedicated test crew is one way of solving it, but as the project progress their workload increase as they have to test all completed tests to ensure regression. So there has to be a better way?

Cucumber is a behavior driven development testing platform. It is originally a Ruby project, but has been adopted to all major languages. The idea behind Cucumber is to create executable tests from your acceptance criteria. So instead of adapting your testing criteria to fit a testing framework, Cucumber makes the testing framework fit your criteria.

So how does Cucumber do this?

By regular expressions, and by adapting the Given When Then pattern of writing acceptance criteria. Let’s elaborate.

Let’s say you were making an calculator which should be able to do the basic operations. We would start by making a user story for the add operation.
To be able to get the sum of some number
I would like to input a series of numbers and get the correct sum
So that no errors

Given I want to add the numbers “10” and “15”
When I press equals
Then the result should be 25

Given I want to add the numbers “1”, “-6” and “5”
When I press equals
Then the result should be 0

This is how a potential User Story from your client could look like.

To make cucumber understand this, we have to write a couple of step definitions. Cucumber adds java support through the Cuke4Duke project. This project adds some annotations to write your steps.

public Class CalculatorSteps(){
private Calculator calculator = new Calculator();

@Given(“I want to add the number(s) \”(\d*)\” and \\”(+d*)”)
public void addNumbers(int number1, int number2){
calculator.add(number1, number2);

@When(“I press equals”)
public void callEquals(){
result = calculator.sum();

@Then(“the result should be \”(\d*)\”)
public void checkResult(int expected){
assertEquals(“the result does not match”, result, expected); //Junit functions.

That’s it. Now you can begin programming your calculator. Yes that’s right. You always write your tests up front. Cucumber and unit tests.

So check out Cucumber on and start using it.

There is also a .NET version of cucumber called Cuke4Nuke