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
