Dan North wrote:
Hi folks.
When we designed JBehave 2 we made some assumptions and left some
deliberate gaps.
One of the assumptions was that people would run scenarios using JUnit
4. They would then use whichever mocking framework they want - JMock,
EasyMock and Mockito being the three obvious ones.
It turns out some people who want to use JB2 are constrained to JUnit
3.8 - usually due to corporate constraints - or want to use other test
frameworks entirely such as TestNG.
Now in JB 2.0.0 we have a concrete class called Scenario which is
coupled to JUnit 4. After a bit of investigation it appears that:
- it is easy to make it backward compatible to JUnit 3.8
- it is less obvious how to make it play nice with TestNG
- there should probably be an interface of which Scenario is an
implementation, and it should really be called something like
JUnitScenario.
In the few weeks it's been released there has been a small-but-rapid
take-up of JB2, which means a lot of people have already extended the
Scenario base class for their own scenarios. This is a Good Thing :)
So I want to kick off a discussion of how to get to JUnitScenario
without breaking everyone's scenarios (yet). Perhaps we should have
released a 2.0.0-alpha1 to signify things might change before we got to
a 2.0.0 final. Never mind - that's how we learn. (I was one of the
people who said we didn't need to!)
You may argue that it's a lesson - once again - that it's always better
to code by interfaces :-)
Still I think it's better to release when something is stable
than to go through too many alpha/beta cycles.
My initial thoughts are:
- subclass Scenario to create an abstract JUnitScenario and suggest
people use this instead.
- deprecate Scenario in 2.1 to discourage anyone from extending it for
new scenarios
- let the users list know we've deprecated it and to consider moving
their scenarios over to JUnitScenario in 2.1 (this shoud be a trivial
search/replace).
- pull up an abstract base class (AbstractScenario?) that implements an
interface (AcceptanceCriteria? RunnableScenario?) that we can use as a
basis for a TestNGScenario.
Apart from the rename of Scenario - I had already gone through this
process (see previous email I sent, in which I posed the issue of the
backward compat).
So, seeing that backward compat is deemed more important (and I do not
disagree) I've now renamed Scenario interface to RunnableScenario and
reinstated Scenario as deprecated abstract class extending
JUnitScenario. We can then remove Scenario at a later stage, or
perhaps we could simply remove deprecation and leave Scenario to be the
default abstract class.
Like?
Cheers
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
