Most people would agree that testing your code is a good thing. And there is little doubt that modern Test-Driven development practices, when applied well, can produce high quality software that is reliable, flexible and easy to maintain. However, one of the big problems that often happens when developers adopt Test-Driven Development is that they concentrate so much on the tests that they lose focus on what they are actually meant to be testing. This results in writing large numbers of superficial and inefficient tests, without testing the underlying user requirements in any real depth.

Behaviour-Driven Development, or BDD, is considered by many to be a natural extention of Test-Driven Development (or TDD). Test-Driven Development is about designing software with the tests in mind.This tends to make the detailed design of your classes cleaner, more modular and more flexible. In practice, it involves writing your tests at the same time as your code - before, simultaneously or slightly after. As a bonus, if you do it well, you get a high degree of test coverage and a good set of regression tests into the bargin.

Behavior-Driven Development, or BDD, is an excellent development strategy that can help bridge the traditional gap between requirements and implementation. This talk will go discuss the basic principles of Behavior Driven Development, and look at how it builds on and differs from “traditional” Test-Driven Development.

Test-Driven Development, or TDD, is often quoted as an essential Agile best practice, and so it is. It works wonders on green-fields projects and new code bases where you can start afresh and ensure that all your code is both easily testable and well tested. But what about legacy code? (By legacy code, I mean any code that does not have a comprehensive set of automated tests, so you might be writing legacy code as we speak). For most of us, most of the code we will ever work on will not have originally been our own work. And, unfortunately for the software industry, only a small fraction of code can really boast comprehensive unit and integration tests. How can techniques like Test-Driven Development make our work as developers more productive and less frustrating?

Easyb is a very cool way to test your Java application in BDD-style with Java. But wouldn't it be nice to be able to integrate your BDD stories into your Maven build process? The good news is, you can!