Hi Andy.
Picking up from Liz and Shane, jbehave works on two levels. The outer
level provides a framework for automatically running and documenting
stories and scenarios. The inner level works more like junit, in that
you start with examples of how the code should behave, and then
implement enough code to make the examples work. Both levels are
behaviour, just represented in different ways.
I find that starting with stories and scenarios identifies the
"outermost" domain objects and services in the application - the ones
that interact with the real world - for example a Customer or an Account
or a FundsTransferService. To start with, I'll get the scenario running
using mocks and stubs. JBehave reminds me that I haven't actually
plugged in any real code by printing an 'M' (for mocks) instead of a dot
when the scenario runs.
Then I go to the example level (into a more traditional TDD-type mode)
to implement the services I'm currently stubbing, which also fleshes out
the domain objects (and often introduces a bunch more, so this is a
recursive process).
As I get real services and domain objects working, I plug them into the
scenario, until it is now passing using real objects, which is when I
get my dot. So I go from this:
MMMMMMM
to this:
.....MMM
to this:
........
and then on to the pub.
As Liz mentioned, jbehave supports the idea of "pending" behaviour, both
in scenarios and (lower level) example methods. It's a nice way of
having TODO markers that nag you until you get things finished, but
without breaking the build in the meantime. You just say: pending("find
out how remote interface works"); and it throws a special kind of
runtime exception that gets picked up by the jbehave framework.
You can already use WebDriver from jbehave, because at the end of the
day it's just Java. We are currently talking about providing a web
driving abstraction in jbehave itself though, so you could
seamlessly(ish) swap out WebDriver, Selenium or Sahi, say.
I can't speak for the other jbehave devs, but I'm excited about
WebDriver because a) it lets you create meaningful abstractions using
regular java code - so you could have app.loginAs('bob', 'secret');
app.withdrawFunds(100.00); - and that you can use the refactoring tools
in your IDE as the vocabulary in the domain model evolves.
Anyway, welcome aboard, and please share your jbehave experiences with
us so we can make it better.
Cheers,
Dan
Andy Zimmerman wrote:
I've been very excited watching the progress you've all made with
jBehave recently. It looks like I'm finally going to get the
opportunity to write code again, and I'm planning on using BDD (as I
understand it today - I'm sure I'll learn more ;-) ). However, I'm
having one small problem with jBehave: I don't grok how the stories
and behaviours mesh.
I understand (at least at a basic level) how to use behaviours as I
would have used jUnit tests previously. I understand that there is a
two way path between text documentation and code via the Stories
framework. What I don't get is how the (apparently empty) Stories
connect to the Behaviours. What am I missing? I feel like it's
something super obvious, but I'm just not getting it (even after
looking over the Hellbound example code).
It could be due to me trying to stuff my brain with everything that's
happened in my favorite Open Source framework stack since I last
coded, but I'd appreciate any quick insight or direction you can offer.
Thanks,
Andy Zimmerman
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
