Behavior driven development (BDD) is getting more and more attention, and a lot of frameworks are out there to support it. But something is missing in the Java World – a BDD-framework that supports existing ways of writing tests, so that developers actually will use it. Read Article

Now really, if one comes along and renames Rapid Prototyping to "Behavior Driven Development" by adding a number of acronyms and buzzword (injections, ensureThat ...), where Code is basically coded only and when it is needed to satisfy a requirement of the UI, all I can say is "Sancta Simplicitas!". Of course the proponents of "BDD" will now educate me that it is something very different - Naaaah! That said: Of course application are build that way (outside in), because they have to be - The UI is the only thing a lot of peers involved in the definition process will be able to conceive and understand.

Honestly I don't think so. At a first glance I thought the same but I think you're not only prototyping here, you're also describing requirements at a test level. Not sure how does that work in production, but the idea is great. Requirement Document Specification can have loads of traps when written to human reading (ambiguity, misswriting, requirement conflict, etc), but if you add a logical layer under/above it to make sure these bad situations are cleared I think it's a great idea. However I must agree that the wave of acronyms that we have to deal with everyday is really painful. cheers!

Thanks to you and others for feedback! If I could have one minute of your time to do the BDoc test run, I would also appreciate the comments on how the report for your project look like. It's really easy, just follow http://code.google.com/p/bdoc/wiki/HowTo. One thing is to comment theory and acronyms, another thing is to try it out :-)

The UI is the only thing a lot of peers involved in the definition process will be able to conceive and understand.

I agree with you, the UI is important when getting acceptance from the user. But it doesn't have to be the only thing that the users conceive and understand. Business logic put into objects, tested with unit tests, could with BDoc create a report that gives value to the users / customer. That said, you don't have to show the BDoc to the end users or the customer. Just showing the BDoc report among developers is enough to get a discussion started about what the software really should do, or what is does. You don't even have to show it to others, if your are developing alone. BDoc is a view on your tests, different from you IDE view, giving you the benefit of just being another view. Try it!

I'm not sure if the presented framework fully supports the core ideas behind BDD. Focussing on documentation is a valid argument for BDD, but only half of the truth - you can even have ordinary unit tests that act as documentation tests. But looking at the presented 'Specs' within this framework, you'll still handle tests (mainly focussed on units that reflect the structure of your code, not focussed on little pieces of behaviour in a certain context) While it's good step towards BDD (in the case of focussing on documentation), there may be other frameworks in Javaland, that provide a more specification oriented vocabulary which may provide a better support for getting the core idea of TDD as a design process (rather than a verification method). You may have a look at JDave, JBehave or beanSpec ...

I've made a lot of compromises to support my main requirement for BDoc: Support existing ways of writing tests, while still getting a new valuable view of the code, readable be people inside and outside the development team. So you might call it support for Behaviour-Driven Development Light :-) To change how developers work is hard, so I won't go there. Supporting existing ways of writing tests makes it so much easier to get developers to improve the quality of their unit tests. Confronting developers with tests they wrote one month ago, I have experienced that they have difficulties explaining what the test does. BDoc lets the developer get another view of their tests, if they understand what they read in the bdoc-report, chances is that they (and others) will understand what the test does one month from now. BDoc might not be the tool for the future, but its a good tool for using right now!