Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Achieve the Best of Two Worlds with Behavior-Driven Development

Both Extreme Programming and Scrum are more effective when practiced together—and even more effective when combined to form Behavior-Driven Development.


advertisement
uch of agile software development methodology is grounded in the lean manufacturing principles developed and perfected by the Toyota Motor Company, and translated to software production by a number of software luminaries in the 90's. Toyota understood that eliminating waste was essential to achieving its goals, and it understood that a rigorous pursuit of quality for its processes and products was essential to eliminating waste.

The rework caused by defects and the downstream difficulties brought about by components built earlier in the process are powerful inhibitors to throughput. Lean and agile approaches depend on frequent inspection and feedback of work product at every stage of the process to avoid creating waste. Rich and frequent communication along with the focus on quality is what allows the advances in productivity and flexibility achieved by agile organizations. Scrum, XP, and the Communication Gap
Extreme Programming (XP) brought mainstream attention to agile development. XP borrowed planning practices from Scrum, but in the beginning, Scrum was a bit of an unknown compared to XP.

It wasn't long before it became clear that using Scrum and XP together brought needed organization and planning practices together with agile engineering practices. Yet since XP and Scrum are separate methodologies, there are gaps between the two that sometimes make for a bumpy ride when transitioning from Scrum's planning practices to XP's software engineering practices.

When formulating acceptance criteria, any new criteria that surface in the process of elaborating on a user story in code are captured directly in code, and can be communicated back to the customer later if necessary.
XP and Scrum necessarily have two processes in play on agile teams addressing different aspects of software production. Behavior-Driven Development (BDD) comes out of the friction between these two processes. BDD tightens communication and feedback across the gap between XP and Scrum. It offers some new ways to use old practices—and these in turn bring more focused workflows to agile development that might be considered a methodology of its own.


An Old New Thing
Agile project teams use XP and Scrum together because each has a focus that the other doesn't have; but XP and Scrum also have a lot of common ground and that makes them natural partners. With a layer of Behavior-Driven Development over XP/Scrum, the individual agile practices tend to flow together with fewer coarse transitions between analysis, design, development, and testing activities.

Getting XP and Scrum to play well together involves being slightly stricter with some of the practices, as well as tweaking some of the practices subtly so that they complement each other better. BDD creates more harmony between the user story practices from Scrum and the Test-Driven Development (TDD) practices from XP. The user stories practices represent analysis and specification in agile projects, while TDD represents software design.

The resulting increased fluidity between analysis and design is brought about by a stronger focus on acceptance criteria. Acceptance criteria are those parts of requirements that specify when a requirement has been satisfied by shippable software. BDD borrows Domain-Driven Design's focus on establishing and evolving a shared language (ubiquitous language in DDD parlance) used by the team in requirements, abstractions (class names, variable names, methods, database tables, columns, etc.), specifications, documentation, and all manner of project artifacts, as well as in conversations and other communications between members of the team, customers, and stakeholders.

BDD uses "Context/Specification" test style in its TDD practice to arrive at smaller, simpler, and more focused test groupings that more readily document the system. Context/Specification tests focus on how the system and its modules and units behave in specific usage contexts rather than on how individual classes and methods have been implemented. The contextual perspective more naturally reflects the system's user stories, and often leads to a more fluent understanding of the customer's expectations of the system. Contextual specification helps keep developers focused on the desired user experience, and produces test code that is more navigable, more discoverable, and generally more understandable—which is itself a boon to agility, raising productivity and quality to a yet higher level.

It's Still TDD
Nothing in Behavior-Driven Development changes Test-Driven Development's mechanics. Everything that you do today with TDD is still done in exactly the same way. Not even the use of Context/Specification style tests changes the essential work style and goal of practicing of TDD. Red-Green-Refactor, test-first programming, friction-aversion, design principles and practices, micro-incremental design, and all the usual suspects are still in play. It's perfectly valid to continue to refer to TDD when talking about those parts of the practice that are specific to TDD mechanics. It's not just because BDD is the new thing that developers immediately have to replace TDD with BDD in their vernacular—especially since the terms aren't always synonymous. BDD covers more ground than TDD, although it has TDD at its core.

It's About Design
Like Test-Driven Development, Behavior-Driven Development is concerned with software design. As with TDD, it leverages friction found in testing to indicate the presence of subtle design problems that will cause downstream software production throughput problems, causing the code and the system itself to be harder to work with each time new code is integrated into the whole. TDD is often specifically about the design of code units and modules such as classes. BDD is also concerned with unit design, but its focus addresses a much broader range of design concerns.

BDD is used in support not only of unit design, but also in support of shared language design, test design, and even user experience design.

Editor's Note: This article was first published in the May/June 2008 issue of CoDe Magazine, and is reprinted here by permission.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap