On 11/6/07, Mauro Talevi [EMAIL PROTECTED] wrote:
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.
I completely agree. JBehave was started with a simple premise, namely: I
wonder what junit would look like if it was completely behaviour-driven and
we got rid of the word test. Since then it has grown, but we have never
really revisited that initial premise.
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.
Yep. We all agree that the story level is the real value of a BDD framework.
At the code level it's just about getting rid of the word test, which is
easy.
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.
JBehave 2 doesn't even need to have an opinion about mocking frameworks. We
would have to work quite hard not to support mocking.
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.
I agree. JBehave 2 will be a story runner framework that sits on top of
pretty much any runner - be it JUnit 4, WebDriver, Selenium,
Selenium-inside-JUnit, doesn't matter.
We can keep jBehave 1.x for JDK 1.4+ and have jBehave 2.x require JDK 1.5+
Yes. JBehave 2 should leverage the Java 5 goodness that's been around for a
couple of years now. I'm happy to make that decision.
I would discuss the option outlined above further before taking decisions.
I am keen to see the vision for JBehave 2 discussed and fleshed out on this
list (subject to Liz and I having the usual despot veto) and then get to a
2.0 release as quickly as possible. I think the feature set for a viable
story framework - without the overhead of writing our own runner etc. -
should be a relatively small amount of effort if we're smart about it.
On a personal note, I'd like to develop it using mercurial rather than
subversion, having discovered that moving from centralised to distributed
source control is almost as liberating as having source control in the first
place. So in terms of logistics, we would keep http://jbehave.org (which
needs some care and attention) on its existing server and host a mercurial
repository there too, and use codehaus's infrastructure for the mail lists.
The jury is out for issue tracking - I'm not that wild about jira so I'm
open to suggestions.
Cheers,
Dan
