Hi Liz,
Elizabeth Keogh wrote:
Hi Mauro,
I can see you're working on my favourite thing - the stuff that turns
stories into code automatically.
an itch that had to be scratched :-)
Ryan has volunteered to help us with JBehave, and I foolishly suggested
he might help without realising you were active on this bit. Here's the
list of stories I sent to Ryan, which I would very much like to be in
place by end September.
I would aim for much sooner ;-)
1) As a developer, I would like to create a new Story class from a story
text file so that I don't have to do it manually. (This includes the
narrative.)
2) As a developer, I would like to create a new Scenario class from a
story text file...
3) As a developer, I would like to create a new Given, Event or Outcome
class from a story text file...
4) ... I would like not to overwrite any existing class files from the
Story framework...
5) ... I would like to create two Scenarios from the same story text
file...
6) ... I would like my Givens, Events or Outcomes to take parameters in
their constructors, so that I can maintain a useful hierarchy of classes.
7) ... I would like my story components to have the package structure I
specify, so that I can navigate it easily. (A prefix, with an option for
the givens / events / outcomes / scenarios / stories subpackages).
8) ... I would like newly created methods to throw a PendingException,
so that I don't forget to fill them in.
This is because, when I did the game of life stories, it took me 30
minutes just to turn them into class stubs. That's 30 minutes times
however many people are using JBehave. Dan and I will be running a BDD
workshop using JBehave in October, and I'd love for our attendees to
have this time to do more fun stuff.
Are any of these stories complete? What's still outstanding?
The VelocityCodeGenerator takes a StoryDetails as parsed from a story test file
and for each scenario, generates the code stub of the corresponding events,
givens and outcomes
OTOH, it would seem that current implementation satifisfies stories 3, 5, 7.
Stories 1, 2 are straightforward extensions (given that we have all the info in the StoryDetails -
add a couple of templates et voila' ... ).
Story 4 could easily be satisfied but ATM the sourceDirectory to which it writes is the same
containing the story files. Either add a different param or read from text file - see note below.
Story 8 is easy-peasy - just need to update the templates.
Story 6 requires a bit more thought - can't see it very clearly ATM. Can you
elaborate please?
Note: it may be useful to add to StoryDetails - eg the storySourceDirectory
and the packageName,
which atm are injected into the generator (eg configured in the invocation of
the task/plugin).
But I can imagine it being better to specify these details in the story text file. So that's on my
TODO list.
Can we tie any of your code into an ant task? Or could you please send
us some quick documentation on how to use the code generation (and ant
tasks will be the next story)?
Have a look at the behaviour class or the maven plugin - the Ant task can
easily mirror the plugin.
But it's really quite simple - list stories, load each story, extract the story details and pass to
the generator.
Any doubts, just shout :-)
Note 2: The AbstractStoryMojo has some useful methods to filter stories (actually based on Ant's
DirectoryScanner) that we may move to core, so they can be re-used by both Ant and Maven plugin.
Cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
