Crispin, Lisa - Agile Testing - A Practical Guide for Testers and Agile Teams

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

}

}

This scenario is now executable within the context of the application it serves to validate! The scenario leverages the customer’s exact words, too; what’s more, regardless of the customer’s ability to read code, the code itself leverages natural language: customer.orderPrice.shouldBe 42.50.

By leveraging the customer’s language, the customer has the ability to collaboratively facilitate in validating the system he or she wants built. Also, with development leveraging the stakeholders’ language, there is a direct link between what stakeholders ask for and what they receive. And you don’t even need to understand Farsi to see the benefit in that.

Two of the most common questions we’re asked by new agile teams are, “What about documentation?” and “How can test automation keep up with development in two-week iterations?” Tools such as easyb answer that question with executable documentation using a domain-specific language that everyone on both the customer and developer teams understands.

The goal of business-facing tests that support the team is to promote communication and collaboration between customers and developers, and to enable teams to deliver real value in each iteration. Some teams do this best with unit-level tools, and others adapt better to functional-level test tools.

API-Layer Functional Test Tools

Before Lisa joined her first agile team, testing “behind the GUI” was a concept that sounded good, but she’d never had the opportunity to try it. Fit, and FitNesse, which is built on top of Fit, are functional test tools that grew from the need for the customer team to be able to write and understand the business-facing tests that drive development. With these tools, teams can test business logic without involving the presentation layer.

Fit and FitNesse.Fit (Framework for Integrated Tests) is an open source testing framework that promotes collaboration, which makes it a good tool to help refine requirements. The invention of Ward Cunningham, Fit has enjoyed an illustrious roster of contributing developers. Fit enables customers, testers, and programmers to use examples to specify what they expect the system to do. When the tests run, Fit automatically compares customers’ expectations to actual results.

With Fit, customers can provide guidance using their subject matter expertise to define the examples that the programmers can code against. The programmers participate by writing the fixtures that do the actual checks against the examples. These fixtures use the data specified in the examples to run with the actual program.

Fit tests are automated by fixtures that pass the test inputs to the production code and then accept the outputs, which it then compares with expected results. The test results are color-coded, so it’s easy to spot a failure or exception.

Fit tests are written as HTML tables, but teams can customize Fit so that tests can be written in spreadsheets or whatever form the customers, testers, and analysts find usable.

Learn more about Fit at fit.c2.com.

FitNesse is a web server, a wiki, and a software testing tool that is based on Fit. Originally developed by Robert C. “Uncle Bob” Martin and Micah Martin, it’s an open source tool with an active developer community. The main difference between FitNesse and Fit is that FitNesse tests are written in wiki markup instead of HTML tables, which some users find easier. It also supports creating tests in spreadsheets and importing those into the tests.

Learn more about FitNesse at www.fitnesse.org.

Figure 9-8 shows part of the FitNesse test that was built from the example in Figure 9-4. More inputs were added to make the production code run, but the essential test data is from the spreadsheet. The test results are color-coded green when they pass, red when they fail.

Figure 9-8 Automated FitNesse test from customer example

Another benefit of a Fit or FitNesse type of tool is that it promotes collaboration among different team members in order to come up with the right tests to guide development. Customers, programmers, testers, and others work together to specify and automate the tests.