Jon, an initial implementation has been committed. The behaviour you requested is all verified in the pending.story in the trader example:
https://github.com/jbehave/jbehave-core/blob/master/examples/trader/src/main/java/org/jbehave/examples/trader/stories/pending.story Can you please tried out the latest 3.4 snapshot and let us know your feedback? Cheers On 05/04/2011 11:13, Jonathan Woods wrote: > Great - that's the kind of thing I'm looking to do, so (apart from > generation) glad it's possible. > > Just a few matters-of-opinion on the Pending/Stub choice: > > - I think Pending is more expressive, because it's declaring that the > developer needs to pay it some attention > - generated methods are still pending in the sense that they need > developer attention, just as 'no matching method at all' makes a step > pending > - there is that useful case where a developer might want explicitly to > declare something as pending > - a generated method /might/ actually be a valid implementation, if > it's meant to be a no-op, so it isn't a stub; again, it should be > regarded as 'pending' in the sense that it's pending a developer's > blessing > > Could you give me a hint where I might look in the API to ensure that > stories with no implementations are regarded as completely pending? > Perhaps I'm missing a typical workflow here. > > Jon > > -----Original Message----- > *From*: Mauro Talevi <[email protected] > <mailto:mauro%20talevi%20%[email protected]%3e>> > *Reply-to*: [email protected] > *To*: [email protected] <mailto:[email protected]> > *Subject*: Re: [jbehave-user] Can 3.2 or 3.3 auto-generate step > definitions? > *Date*: Tue, 05 Apr 2011 10:13:47 +0200 > > Hi Jon, > > thanks for your clarifications. > > JBehave can already do all that you describe, with the already noted > exception of generating the method stubs. The steps not matched are > marked as pending in all report formats, and can optionally make the > build fail. > > As for the parameters in the method stubs, having no parameters is the > easy case and the most natural candidate for the method if no other > signature has been found. The template could be used to generate > steps that are more meaningful to the user, but it would not be > mandatory to use a template. > > And we can easily add a @Pending annotation or equivalent (@Stub > perhaps? since once the method has been generated it's not technically > pending) > > Cheers > > On 04/04/2011 10:37, Jonathan Woods wrote: >> Hi, Mauro, and thanks for such a quick response. >> >> I guess I should have familiarised myself with the codebase a bit >> more before flinging suggestions around - apologies. I hope what I'm >> suggesting still makes sense and I'm not reinventing the wheel. >> >> I'll post a separate mail re the 'totality' question. Concerning >> auto-generation of draft step definitions, I should first say what >> kind of usage pattern I'd love to take advantage of, and it's the one >> espoused by Cucumber. By analogy with the typical 'unit test' TDD >> approach, which is something like >> >> - create a test class >> - write a test of some simple requirement of the new class, which >> doesn't exist; compiler croaks >> - create class and enough extra to shut compiler up >> - run test, which fails (if the requirement isn't just 'exists') >> - fix implementation >> - run test, which passes >> >> Cucumber gives you the following: >> >> - CEO gives you the story (!) >> - run tests with story and get told that steps are pending, and get >> given simple skeletons of implementations, flagged therein (more >> later) as pending >> - slap in those draft step implementations >> - run tests >> - get told that steps are pending (through console, in Surefire test >> runs, in Hudson/Jenkins output…) >> - implement steps >> - run tests >> - get told nothing pending but implementation fails >> - implement fix >> - run tests, which pass >> >> In Cucumber, there's lots of flow. There's no need to require >> templates at all for the auto-generation of step >> definitions/implementations, and imho I think this should be the >> default position for JBehave. It's not DRY, and it means you have to >> have written Java before diving in with textual stories - and >> avoiding this is the point of auto-generation, really. >> >> It would also be great if the generated code was as agnostic as >> possible about how the developer wanted to model things. To give an >> example: as a BDD developer I'd like to be able to go straight from this: >> >> Given there is a flight >> And there is a customer >> When the customer books the flight >> Then the customer is shown on the manifest >> >> to Java like this: >> >> @Given("there is a flight") >> @Pending >> public void thereIsAFlight() { >> } >> >> @Given("there is a customer") // note 'Given', even though story line >> is 'And' >> @Pending >> public void thereIsACustomer() { >> } >> >> @When("the customer books the flight") >> @Pending >> public void theCustomerBooksTheFlight() { >> } >> >> @Then("the customer is shown on the flight manifest") >> @Pending >> public void thenTheCustomerIsShownOnTheFlightManifest() { >> } >> >> I can then slap the code into a class, and without doing anything >> else carry out a test run and be told steps are pending. >> >> A few comments: >> >> - @Pending would be a really really useful annotation; cuke4duke has >> it :-). Clearly here it's used to solve that problem you mentioned, >> of the possibility that generated step definitions slip through as >> the real thing; it makes pending steps easy to search for; and >> developers could/should use it themselves as a flag to keep the tests >> honest. (I think Cucumber in Ruby uses a method, or whatever they're >> called in Ruby world, but in Java that presupposes too much about how >> the step implementations are being constructed, and pendingness is at >> the same kind of level as @Given, @When and @Then.) So, pending >> steps are all those for which (in the context being considered) no >> Java can be found, PLUS the steps which are declared as such. >> >> - it would be unhelpful of auto-generated Java to worry about typing >> variables, or identifying them at all. Java developers should be >> free to use whatever strategy they choose. I'm really out on a limb >> here because I don't yet fully 'get' the JBehave parsing approach, >> but I'll try to show what I'm getting at with an example. Supposing >> the story line was >> >> Given there is a flight with 3 passengers >> >> I think it would be best for the generated method to be >> >> @Given("there is a flight with 3 passengers") >> public void thereIsAFlightWith3Passengers() { ... >> >> because for all you know, the developer doesn't want to parameterise >> the '3', but just to assume it. If later the given condition becomes >> something which needs to be generalised/used elsewhere, then it's >> easy for the developer to rewrite as >> >> @Given("there is a flight with $passengerCount passengers") >> public void thereIsAFlightWithPassengers(int count) >> >> and the step will still match, but presumably JBehave magic will >> auto-inject the variable. >> >> Similarly, in the absence of templates (which I'm claiming is >> actually a good thing for a default), there's no way of telling >> whether 'Given there is a job' should be transformed to 'public void >> thereIsAJob()', 'public void thereIsAJob(String job)' or 'public void >> thereIsAJob(Job job)'. The developer should be free to choose the >> strategy, and it doesn't matter that there isn't in general any way >> of knowing (without a template) which they first mean - the generator >> might as well go for the simple no-args strategy, and let the >> developer take control of the flow. >> >> Clearly you'd need some friendly method name generation strategy, but >> I don't think it need be very clever - the generated stuff is just >> draft, after all, but a draft which is immediately useful by virtue >> of flagging its pendingness and pre-performing some of the Java >> ceremony. In general, the @Given annotation value is what matters, >> and the method name should be under the developer's control. So >> 'Given there is a grid (2,3) with 2 pieces on it', it would be fine >> to generate thereIsAGrid23With2PiecesOnIt()' because if the developer >> finds that irksome, they'll change it. >> >> As I said, really sorry if there's something fundamental I'm missing >> which makes all of the above meaningless! >> >> Jon >> >> -----Original Message----- >> *From*: Mauro Talevi <[email protected] >> <mailto:mauro%20talevi%20%[email protected]%3e>> >> *Reply-to*: [email protected] <mailto:[email protected]> >> *To*: [email protected] <mailto:[email protected]> >> *Subject*: Re: [jbehave-user] Can 3.2 or 3.3 auto-generate step >> definitions? >> *Date*: Sun, 03 Apr 2011 12:21:59 +0200 >> >> 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 >> >> >> > >
