On Dec 11, 2008 5:25am, Egil Østhus <[EMAIL PROTECTED]> wrote:
My desire for priority is neither to add complex to the scenario files
nor being able of performing magic within those text files. I would argue
that JBehave is a tool for the developers,
and that it needs to be driven by developers (a discussion we had some
weeks ago, that really was never concluded).
Egil, I'm guessing you're a developer...?
In other projects I've been on, the QAs have been the ones creating the
scenarios. Sometimes the business has been directly involved. JBehave is a
tool designed to help all team members communicate, whether they're
technical or otherwise.
If it's only developers who are using JBehave, you might be better off
naming the steps nicely in code, then calling them in a test somewhere. For
instance:
givenIHaveABalanceOf(100);
whenITakeOut(20);
thenIShouldGetCash(20);
thenMyBalanceShouldBe(80);
There are some reasons why this is more expressive for developers - the
ability to breakpoint and debug on particular steps, the ability to reuse
and refactor easily, etc. I know many projects who use this technique and
find it works very well for them.
JBehave 2 was designed to do one thing differently: allow team members -
technical or otherwise - to capture runnable scenarios more quickly, in
order to get faster feedback by talking about them. It might be a useful
tool for developers, but only if you're using it to have conversations with
a bunch of other people involved in the project! I find those conversations
useful. Otherwise, I wouldn't advise using JBehave (JUnit is just fine on
its own).
So, no; I would not like JBehave to be driven by developers, and certainly
not compromised by developers' needs. It was initially driven by my
frustration with JBehave 1 when trying to do analysis, and I feel strongly
that analysis - whether done by the business, BAs, QAs or developers -
should be the driving role. The language of BDD and JBehave - Given, When,
Then, Scenario, Story, etc. - comes from the analysis domain, rather than
the coding one.
Regards,
Liz.
