Behavior-Driven Development With easyb

Behavior-driven development (BDD) is an iterative, incremental, agile methodology for software development. BDD methodology brings all the stakeholders (business analysts, users, project managers, and developers) together and therefore minimizes the translation between the technical language in which code is written and the domain language used in describing requirements. In BDD, all stakeholders get together to create stories, which describe different requirements using examples (referred to as "scenarios" in BDD). These scenarios are then automated to give quick feedback or regression.

BDD is an outside-in approach, which usually involves creating stories before the actual development starts. The test cases are run iteratively throughout the entire development cycle until all test cases pass. This ensures that there are no regressions and helps development teams deliver clean code that covers all requirements.

easyb, which won a Jolt Award in 2009, is an open-source BDD framework for the Java platform. Its specifications are written in Groovy and executed via a Java runner that can be invoked from the command line, Maven 2, or Ant. easyb has an out-of-the-box reporting tool that provides test results in HTML and XML formats. And easyb supports story-based DSLs with given, when, and then keywords.

easyb is distributed under the MIT license and is hosted at Google code, which provides an accessible Subversion repository. Building easyb requires Groovy 1.6.0 and Gant 1.6.0.

This article provides an overview of various keywords used in easyb to write a story file, the easyb software development lifecycle, using easyb as a test driver, and the different ways in which easyb artifacts can be organized in a project.

Stories

Stories are sequences of events, narratives, or statements between developers and business stakeholders. A story provides a description of a requirement or use case that can be validated. Stories are created using predefined keywords so that a use case can be described completely.

Narratives are written in the beginning of a story file. Narratives give an overview of a story:

narrative "regarding stock  availability", {
	as_a "customer who places order on online retail portal"
	i_want "to be able to see a confirmation message about availability of stock"
	so_that "I know whether my order can be completed successfully or not."

Scenarios help describe easyb stories. Every scenario has a precondition described by given, a test execution described by when, and validations described by then:

scenario "A customer orders a music player which is in stock",{
	given "There is music player in stock",{}
	when "A customer orders a music player",{}
	then "The order should be placed successfully and a success message should be displayed to customer.",{}
}
scenario "A customer orders 5 AA batteries out which only 3 AA batteries are in stock",{
	given "There are 3  AA batteries in stock",{}
	when "A customer orders 5 AA batteries",{}
	then "The order should not be placed and a failure message should be displayed to customer",{}
}

Fixtures are a precondition that needs to be set for all scenarios using before. A precondition that needs to be executed before every scenario is set using before_each. Usually, these keywords are used to perform activities, such as initializing variables, bouncing servers, etc., which must be performed before scenarios start running.

before "bounce tomcat server", {
	given "server is up and running", {
		bounceServer();
	}
}

If there is a requirement that the server should be bounced before every scenario, then the before_each keyword should be used.

Shared behaviors, as the name suggests, are basic scenarios that are constructed if there is a certain functionality that is shared across many scenarios in the story file. This scenario is later referred to in other scenarios.

shared_behavior "login", {
	given "a valid user", {
	User.isValidUser().withUserName("username").withPassword("secret");
	}

	when "the user logins with valid credentials ", { Application.login() }
}

scenario "user can see a welcome page when the login is successfull", {
	it_behaves_as "login"

	then "the welcome page is displayed", {
		//code to inspect elements of welcome page
	}
}