Elizabeth Keogh wrote:
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.
IMO jBehave 1.x has tried to re-invent the wheel too much, being at a
unit-test level quite similar to JUnit. In this sense, we need to not
overlap with existing frameworks. I agree with your proposal to not
compete but complement JUnit. A good example of this approach is jMock.
This holds true for java-code unit-testing. On the other hand, what I
feel is the area of most potential for jBehave is integration testing,
using text-based scenario runners. This is where I feel we need be more
active and where BDD could be a real winner.
I tend not to use mocking frameworks, so probably won't add them in the
first release.
I tend to use them quite a bit and we think about to integrate them as
well from the start. Eg a simple facade to access a jMock Mockery would do.
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.
Why not simply start discussing version 2.x of jBehave at Codehaus?
I don't honestly see the rationale in kicking off another project.
It's quite common for OSS to start work on a 2.x branch that does not
require backward compat with 1.x and learn from the lessons of the
development thus far.
We can keep jBehave 1.x for JDK 1.4+ and have jBehave 2.x require JDK 1.5+
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.
I would discuss the option outlined above further before taking decisions.
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
