Yes, the Embedder is core entry point for running stories, as explained in http://jbehave.org/reference/stable/running-stories.html
If you feel the docs could be improved, don't hesitate to provide these improvements via creating a clone via github and publishing a pull request. Cheers On 07/04/2011 06:23, Jonathan Woods wrote: > 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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
