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]> Reply-to: [email protected] To: [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]> > Reply-to: [email protected] > To: [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 > > > >
