Agile Testing: A Practical Guide for Testers and Agile Teams

Some of the many BDD tools available as of this writing include easyb and JBehave for the Java platform, NBehave and NSpec for .NET, and RSpec for Ruby. These tools, like the XUnit tools, are intended for use by programmers to guide coding, but they can also be used to express business-facing tests that drive development, involving customers more closely in the development process.

Behavior-Driven Development

Andrew Glover, president of Stelligent Incorporated and author of books including Continuous Integration and Java Testing Patterns, explains the thinking behind one of the BDD tools, easyb.

assertEquals(42.50, order.price(), 0.0). Without examining the context in which this statement appears, this code is somewhat incomprehensible. Now imagine you don’t even read code—that is, you are a stakeholder asking (actually paying) for new features. The previous code statement might as well be Farsi (assuming you can’t actually read Farsi!).

order.price().shouldBe 42.50. While the context in which this statement appears is still absent, this line of code is a bit more coherent. In fact, it reads like a normal sentence (and this time knowledge of Farsi isn’t required!). Stakeholders, in this case, could understand this code if they chose to read it; on top of that, it turns out that this line of code essentially matches what they asked for in the first place. This line of code describes behavior in a more literal manner too—the code uses a normal everyday phrase like shouldBe, which is distinctly different than the previously written assertEquals.

Both lines of code from the previous paragraphs convey the same meaning and indeed validate the same requirement, yet the latter one comes awfully close to leveraging the customer’s language. This is a fundamental point of the notion of behavior-driven development, which strives to more appropriately validate a software system by thinking in terms of the term “should” rather than test. In fact, by focusing on behavior and closely modeling behavior after what stakeholders ask for, behavior-driven development converges on the idea of executable documentation. Indeed, through leveraging a stakeholder’s language, there is a decreased impedance mismatch between what he wants and what he ultimately receives; moreover, employing a stakeholder’s language facilitates a deeper level of collaboration between all parties. Listen to how a conversation might go:

Stakeholder: For the next release of our online store, our Gold-level customers should receive a discount when they make a purchase.

Developer: What kind of discount—what criteria do they have to meet in order to receive it?

Stakeholder: When they have at least $50 dollars in their shopping cart.

Developer: Does the discount increase based upon the amount, or is it fixed regardless of the value of the shopping cart?

Stakeholder: Good question—the discount is fixed at 15% regardless of price. So, given a Gold-level customer, when the shopping cart totals $50 or more, it should receive a 15% discount off the total price.

The last statement of the stakeholder is key—note how the requirement has been specified and the means for validating it. In fact, the stakeholder has essentially narrated a specific scenario in a larger story related to discounts.

Given this scenario, a developer can take the stakeholder’s comments—word for word—and execute them. For example, one behavior-driven development framework, dubbed easyb, facilitates system validation through a domain-specific language that supports stories and scenarios. For example:

scenario "Gold-level customer with $50 in shopping cart", {

  given " a Gold-level customer"

  when "their shopping cart totals $50 or more"

  then " they should receive a 15% discount off the total price"

}

Of course, this particular scenario doesn’t actually do anything (other than capturing the stakeholder’s requirements, which is still quite important!); consequently, it is considered pending. This status alone conveys valuable information—stakeholders can, first and foremost, see their words as a means to validate their requests, and secondly, gauge if their requirement has been fulfilled. After this scenario has been implemented, it can, of course, take on two other states—success or failure, both of which serve to convey further status information to interested parties.

Now, with a collaborative scenario defined, development can proceed to the implementation—the beauty in this case is that they can directly implement the desired behavior inline with the requirements, like this:

scenario "Gold-level customer with $50 in shopping cart", {

  given "a Gold-level customer", {

        customer = new GoldCustomer()

        }

  when "their shopping cart totals $50 or more", {

        customer.shoppingCart << new Item("widget", 50.00)

  }

  then "they should receive a 15% discount off the total price" , {

        customer.orderPrice.shouldBe 42.50

        }

}