Hi all, First off, Dan and I want to thank all of you for the hard work you've put into JBehave 1.x. It's the first framework of its kind that's ever been done, and it's played a crucial role in teaching BDD to people around the world. It's been an absolute pleasure to post snippets of readable, executable code to the XP group; to personally experience that 'aha' moment when my scenarios pass; to open people's minds to the possibilities of programming in the same language they use for conversation with the business.
JBehave started three years ago, when Dan was still working out BDD and I was new to Agile. It's evolved over time, and we've all added features we thought would be useful. The truth is that, at the moment, there's little reason for anyone to use JBehave on a grown-up application (by which I mean most of the apps that big development teams, as opposed to single people, create). The latest versions of JUnit and JMock / EasyMock are superior at a unit level, and I reckon the time spent learning JBehave's framework could be more usefully spent learning Ruby and picking up RSpec, which has a far nicer interface than ours. We don't believe JBehave is dead, or even relegated to the status of a teaching tool. We do believe that it requires some serious rework before it will be usable on grown-up projects. For a while now, I've been writing a sudoku solver, and the prototype is done. I need something easier than JBehave to drive the rest of the development. I have two choices: - learn Ruby and use RSpec on JRuby - drive out a new framework, with the reliability of JUnit and the two Big Mocks at a unit level, and the ease (and lack of duplication) of RSpec at a scenario level. The first would be easy. So, of course, I'm going to do the second. This framework is going to be stable, robust, easy to use and suitable for large, team-driven projects. No features will be added which aren't needed for a particular project (which means that every feature will have a project which gives an example that feature in action). I will probably be driving it with both Swing and WebDriver (one Engine, two possible guis). I forsee the following features being useful (but am not going to write them unless I need them): - Unit-level examples based on JUnit 4 (so no need for a separate Behaviour runner; we will be able to use all of JUnit's pretty plugins and Ant tasks) - Ensure.that using Hamcrest's matchers - Plain text scenarios and a scenario runner, possibly backed by JUnit just to take advantage again of the graphics, Ant tasks etc. - The ability to tag scenarios (this allows for regression tests, and for one scenario to cover multiple features / stories) - Ant tasks to be able to filter on these tags - Java 5 compatible API. I tend not to use mocking frameworks, so probably won't add them in the first release. I have no idea where this project is going to sit, or what it's going to be called. Ideally, I'd like it eventually to become or merge with JBehave 2.0, since I don't see a benefit worth the cost of investing in JBehave in its current form. I expect it to take a year or so to produce, and I expect it to be in common use on real projects two years after that. Dan and I are going to kick this off to start with, then open it up carefully to a larger developer base. I appreciate that a huge amount of work has been invested in JBehave, and I don't want these proposals to seem disrespectful. I will probably be drawing deeply on JBehave's codebase for the implementation of many of these features, just as I imagine I'll be drawing on RSpec for help in developing new interfaces. Obviously, this will mean that I'm not going to be working so much on JBehave itself. If you have your own proposals for the future of our little open-source framework, please let us know what they are. Cheers, Liz. -- Elizabeth Keogh [EMAIL PROTECTED] http://sirenian.livejournal.com http://jbehave.org
