Behavior-driven development, or BDD, has attracted a lot of attention via RSpec in the Ruby community, but BDD's roots stem from JBehave, a Java based framework modeled off of the xUnit paradigm. But JBehave isn't the only framework available for Java developers-- with the advent of Groovy, new options are available for embracing BDD in the spirit of RSpec's innovative behavior based DSL.

In this session, we'll look at what BDD is, how it is an evolutionary result of Test Driven Development, and how it shifts the traditional testing vocabulary from being test-based to behavior-based. You'll also see that this subtle shift in thinking facilitates writing behavior classes first, which is the ultimate goal of TDD style thinking in the first place.

We'll examine RSpec in an effort to understand why BDD is catching on quickly in the Ruby community and then we'll study JBehave's framework for literate programming with expectations along with its Story framework for building executable user stories. With a solid understanding of JBehave, we'll probe some of the more innovative features of Groovy (including building DSLs) which have yielded the easyb BDD framework.

This session will walk attendees through a series of iterations on a fictional Java project where an automated build system is created that facilitates compilation, testing, inspection, and deployment. This build system is then plugged into the Hudson CI server and as features are coded using Agile techniques like developer testing, attendees will ultimately see firsthand how a Continuous Integration process reduces risk and improves software quality.

The practice of Continuous Integration facilitates early visibility into the development process by regularly conducting software builds, thus integrating disparate software pieces earlier than later, which often times minimizes the interval between when a defect is coded and when it is discovered. Often times though, Continuous Integration is thought of as a tool, which leads to a false sense of ease when it comes to adopting a Continuous Integration process.

This session will walk attendees through a series of iterations on a fictional Java project where an automated build system is created that facilitates compilation, testing, inspection, and deployment. This build system is then plugged into the Hudson CI server and as features are coded using Agile techniques like developer testing, attendees will ultimately see first hand how a Continuous Integration process reduces risk and improves software quality.

The spectacular success and market penetration of the iPod, Agile software development principles, Twitter, and even Google are just a few examples of minimalism in action.

Yet, there are countless counterparts to each success previously listed that, unfortunately, didn't make it; what's more, each counterpart tried to solve the same complex problem. Was it market timing, smarter people, access to capital, savvy marketing, or a combination of any of these aspects that made the difference? Or was it because when it comes to coding, design, functionality, project teams, and even testing, less is, indeed, more?