You could just bake it into the story and scenario structure: Story: Santa delivers presents Tags: christmas, target_iteration=6
In order to reward good behaviour Santa wants to know who has been naughty and nice So that he knows who to leave a present for Scenario: I've been nice Tags: warehouse, route, priority=high Given it is Christmas And I have been a good boy When Santa does his rounds Then he stops at my house And leaves a present under my tree Scenario: I've been naughty Tags: route, priority=high Given it is Christmas And I have been a good boy When Santa does his rounds Then he stops at my house And leaves a piece of coal under my tree Scenario: Everyone is away Tags: priority=low Given there is no-one home for Christmas When Santa does his rounds Then he doesn't stop at my house The first scenario has the additional tags of "warehouse" and "route" so we know those are aspects of the particular scenario (the warehouse elves will have to find me a present and the routing team need to ensure Santa stops at my house). Something like that anyway. Tags are just tags. We shouldn't over-complicate them. Cheers, Dan 2008/12/12 Egil Østhus <[email protected]> > I think I like your tag approach, this gives the flexibility to attach > different kinds of information to the scenarios and not enforcing certain > template. > Not sure were the tags would live though? My first impression is that these > tags should be part of the text files, is this in the lines of what you were > thinking? If so; I share Liz' concern that the scenario files are getting > more complex, or unnecessary complex. I guess what I'm trying to say, is > that I like the idea of the ability, just not experienced enough to see were > this information best fits. > > Cheers, > Egil > > On Fri, Dec 12, 2008 at 8:30 AM, Dan North <[email protected]> wrote: > >> 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/ >>> >> >> > > > -- > See my pictures at > http://www.flickr.com/photos/13150...@n08/ > > free code-giveaways at http://codeisland.blogspot.com/ >
