Behavior driven development with EasyB (and vs. TestNG)
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:
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.
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.
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.
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.