Hi Egil. I'm seeing a couple of interesting things here which are worth calling out.
The narrative, or blurb, is designed to be an unstructured bunch of text. If you tend to use the As a.. I want.. So that.. template, the narrative could contain additional notes or information to supplement that. On the other hand it might be the whole description. It's entirely up to you. However, you are suggesting additional fields like a priority, and I could imagine a size estimate, MoSCoW ranking, or other useful things. So what if we could tag stories and scenarios? The tags could be either values or key=value pairs. That way I could tag all the scenarios that were about *security*, *account_admin*, *priority=must_have*. I could do the same thing at the story level (which would cascade down to all the scenarios in that story). Then I could filter based on tags - and values - so I could show my security stakeholder all the scenarios tagged as *security*, and demonstrate that all the *priority=must_have* scenarios & stories were working. Perhaps the scenario class could be aware of a system property called JBEHAVE_TAGS or something? Cheers, Dan 2008/12/11 Egil Østhus <[email protected]> > Hi Elizabeth, > > I think the subject of my mail should have been more in the lines of > "request for comments", that is my intention with this dicussion. As you > understand, I'm playing around with JBehave to see how I get the best use > out of it. As I go, I like to discuss my thoughts to get feedback. From what > you are saying, I see that I have another understanding of how the scenario > files is used. My approach is to collect all the different scenarios that > belongs to a story in a story file, rather than each scenario in a separate > file. To me it seems to be just too many files in the latter approach, but > as you say, different teams have different preferences. With the method > called beforeStory(Blurb blurb) I was under the impression that the blurb > meant to be the story itself, I might be wrong on this. On the other hand, > if JBehave is capable of fitting all the different takes on this matter, it > just shows the value JBehave is bringing to the table. :) > > My desire for priority is neither to add complex to the scenario files nor > being able of performing magic within those text files. I would argue that > JBehave is a tool for the developers, and that it needs to be driven by > developers (a discussion we had some weeks ago, that really was never > concluded). My intention is just to have a way to say what scenarios gives > the most value to the customer, to keep this info in the scenario files, and > to take advantage of this info in the ScenarioReporter. From my experience, > the priority is something that fits well with the business analyst, and is a > great tool when discussing what is next. What do you think? I'm happy to > learn from your experiences. :) > > Cheers, > Egil > > > On Wed, Dec 10, 2008 at 3:57 PM, Elizabeth Keogh <[email protected]> wrote: > >> Hi Egil (and Mauro), >> >> Blurb means "a brief summary or description of a work". It's not a >> data type as much as a word that I felt described exactly what was >> there; a brief summary. It might be in narrative form; it might be a >> comment about the scenario. >> >> "Narrative" might be better. However, I don't have "Story: <title>" in >> my scenarios; it really is just Blurb for me. If you add a title, >> you'll be forcing others to adhere to that template; they may not want >> to, especially if their scenario files really are single scenario >> files. Perhaps you could find a way to convert the Blurb to your Story >> using a converter of some sort? >> >> I'd also prefer generally that we didn't rename existing classes until >> 3.0 - it tends to break things! Other people may have implemented >> their own reporters too. >> >> Re GivenScenario vs. GivenStory - A scenario is a series of steps >> which leave you in a clearly defined state. A story has a collection >> of independent scenarios - so running them to leave you in a defined >> state makes no sense to me. >> >> I can understand wanting priority. I can also understand wanting to >> reuse scenarios. The two things are very different, though! If you're >> using priority to ensure that a scenario sets up context for another >> scenario, that Given will be magically performed, and hidden from >> anyone who tries to replicate that scenario manually by reading your >> scenario text. >> >> As soon as you do that - use magic in your scenario files - you're >> making it impossible for the business to follow them, and you might as >> well be writing the scenarios directly in code. >> >> I'm really glad you're experimenting with the flexibility of JBehave. >> It makes me happy to see that it does most of the things users want it >> to, or can be adapted! Please let us know how the HTML reporting goes, >> and remember those of us out there who may be doing things a bit >> differently to you. :) >> >> Cheers, >> Liz. >> >> -- >> Elizabeth Keogh >> [email protected] >> [email protected] >> http://jbehave.org >> http://lizkeogh.com >> >> --------------------------------------------------------------------- >> To unsubscribe from this list, please visit: >> >> http://xircles.codehaus.org/manage_email >> >> >> > > > -- > See my pictures at > http://www.flickr.com/photos/13150...@n08/ > > free code-giveaways at http://codeisland.blogspot.com/ >
