Ah. I see that Embedder does exactly what I was suggesting below :)
On 04/04/2011 18:29, Jonathan Woods wrote:
Hi, Mauro.
Re my 'totality' comment: I guess I'm thinking of a model of usage in
which JBehave is told where to get stories (text), and where to get
step implementations/definitions (Embeddeds/Java), and provides a
unified view of the two - and of the test run context. I see know
that it's possible with the underlying API, but is there something
which could be layered over the top to model this more explicitly?
I see now the Maven plugin must already be doing something like this.
Perhaps something like an ExecutionContext could be factored out,
making similar functionality available in non-Maven contexts. An
ExecutionContext would have a Configuration, and therefore a source of
stories and a source of implementations, and would be able to combine
the two to come up to expose
- those stories none of whose steps are implemented anywhere (stories
with all steps pending)
- those stories which have non-pending definitions/implementations for
some but not all steps (stories with some steps pending)
- a collection of stories which have implementations for all their
steps (stories with no steps pending, and which are therefore
executable as a test)
It would also model which stories have actually been executed, with
what results, in this context.
Jon
Hi Jonathan,
thanks for your feedback.
Yes, auto-generation of Java method stubs is not yet implemented.
JBEHAVE-148 is not difficult to implement and I've scheduled it for
3.4. The team needs to be well aware though that the stub itself is not
sufficient and it needs to be implemented. In fact, the risk is that
these stubs may be generated and left unimplemented and may give the
impression of a successful implementation as the steps are then shown as
"green". That said, if used properly, stub generation can be a useful
tool.
Also, I would not say that JBehave "typically starts only in Java world,
and only then looks for matching text stories. Stories which match
nothing are just invisible." JBehave, like Cucumber, parses the text
input and then matches the steps found to methods. So its
text->executable methods, not viceversa. The methods need not be just
in Java, e.g. Groovy is supported. JBehave could support other
scripting languages like Ruby.
JBehave has always report steps that are Pending, i.e. steps that are
not matched by any method. By default it just marks them as Pending
(yellow in HTML reports) but can also be configured to fail and stop if
it finds any pending steps.
Also, the search for existing matching methods of a given textual step
is already supported - have a look at the Web Runner for a UI to this
functionality. It is available in non-web context via the Core
Embedder.
I'm not sure what you mean by "- is told about the totality of story
locations".
Cheers
On 02/04/2011 22:02, Jonathan Woods wrote:
Congratulations to the team on the release of 3.3.
I'm new to JBehave, and even to BDD. A Rubyesque colleague recently
showed me Cucumber, and while I love the concept and the execution, I
really want a Java equivalent because that's my team's first language
and it will open up many interesting pathways of development. And
besides, I'd like to be able to hack on it.
I looked at cuke4duke, but JBehave 'feels' a closer fit for our team.
That said, one thing cuke4duke has which JBehave seems not to is the
ability to auto-generate Java step definitions. Am I right? Is this
still missing from JBehave? I've seen JBEHAVE-148, btw, which is
still unresolved.
It's a killer feature, because it really gets you to that sweet spot
where you can 'write the code you would like to have' at the very top,
and let everything cascade down from that. I know step definitions
are really easy, but I can really see my team - who are BDD (even
TDD!) resistant - blowing this up into a big issue.
afaict, JBehave typically starts only in Java world, and only then
looks for matching text stories. Stories which match nothing are just
invisible. Ideally, I'd be able to use or naturally configure up
something which
- is told about the totality of story locations
- searches for matching Java implementations
- generates Java for missing story components, outputting to some
configured path
Better still, it would be great if there were something which put all
text stories and all Java step implementations into the mix, and
helped to make the difference between the two zero.
Jon
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
