I heard about BDD a couple of months ago and did not really pay attention. Just some weeks ago I thought that maybe I could improve our test and/or documentation. So I decided to give it a shot with the BDD implementation easyb.

According to Wikipedia:

Behavior Driven Development (or BDD) is an Agile software development technique that encourages collaboration between developers, QA and non-technical or business participants in a software project. It was originally conceived in 2003 by Dan North as a response to Test Driven Development, and has evolved over the last few years.

So I took the chance to sketch out a little example and to test it against readability.

This is the class which I would to test with BDD and classic TestNG.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

package net.wehrens.easyb;

import java.util.ArrayList;
import java.util.List;

public class Car {
  private boolean engineInstalled;
          private int doors;
  private List<Wheel> wheels = new ArrayList<Wheel>();

      public void addDoor() { doors++; }
      public void addEngine() { engineInstalled = true; }
      public boolean isEngineInstalled() { return engineInstalled; }
          public int getDoors() { return doors; }
          public void addWheel(Wheel p_wheel) { wheels.add(p_wheel); }
          public List<Wheel> getWheels() { return wheels; }
}

The testcode in easyb looks very descriptive (and even my Product Owner can understand what’s happening). It uses Groovy to create it’s own DSL for writing tests. Even if I don’t explain any more you have a good chance to understand it at the first read.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

import net.wehrens.easyb.Car
import net.wehrens.easyb.Wheel

scenario "make a new car with one door" {
given "a new car" {
car = new Car()
  }

  when "a door is added", {
       car.addDoor()
      }

  then "car should have one door", {
car.doors.shouldBe 1
  }
}

scenario "make a car with an engine", {

  given "a new car", {
car = new Car()
  }

  when "an engine is added", {
car.addEngine()
  }

  then "the car should have an engine", {
ensure(car.engineInstalled)
  }
}

The TestNG version of this test looks a little bit tighter but not as easy to understand for non programmers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

package net.wehrens.easyb;

import org.testng.Assert;
import org.testng.annotations.BeforeMethod;
import org.testng.annotations.Test;

public class CarTest {
    private Car _car;

    @BeforeMethod
    public void setUp() {
        _car = new Car();
    }

    @Test
    public void testAddEngine() {
        _car.addEngine();
        Assert.assertTrue(_car.isEngineInstalled());
    }

    @Test
    public void testAddDoor() {
        _car.addDoor();
        Assert.assertEquals(_car.getDoors(), 1);
    }
}

The big advantage I see here is that non technical people could be able to design test, how the code should behave, what the results should be. This is an often underestimated problem when communicating with the requirements engineers. Just write the BDD tests and the developers make sure they will turn green. The neat thing is that easyb has maven 2 integration and an IntelliJ Idea plugin. This makes working with it a breeze.

Sure sounds easy, but I by myself did not had a chance yet to try that out in a more complex environment…maybe stuff for a later post.