Hi again, Just encountered another question:
Is it possible to create an overview of which Meta tags are presently available? Just to have a constantly updated overview of the tags that one can use when authoring stories and scenarios and again avoiding duplication of tags with ever so slightly different syntax? In article <[email protected]>, Christian Taylor <[email protected]> wrote: > Hi Mauro, > > Thanks for the input. I will have a look at the WebRunner and hope that > we can fit it into our process. > Our aim is to have a tool for authoring stories which offers > autocomplete on annotations and "keywording" feature for the meta info. > I hope this is adressed soon. If we have enough pull for that > functionality we will work on it - but it's early days. > > I may be worth mentioning that all unit-tests are specified, managed and > implemented by the developers almost exclusively. The test team only > deals with functional tests and GUI stuff. > > Thanks for the prompt replies by the way. :) > > /Christian > > > In article <[email protected]>, > Mauro Talevi <[email protected]> > wrote: > > > Hi Christian, > > > > the issue you pose is a very good one indeed. > > > > At the heart of BDD is the concept of creating a DSL - domain specific > > language - that is shareable by all team members and stakeholders. > > > > The aliases are not intended to replace the communication and > > interaction amongst those developing the grammar. Rather they are meant > > to allow the evolution of the language. The aim to not block the > > refinement of the way the behaviour is expressed because of fears that > > it would break the build. > > > > Ultimately, though, as Brian was rightfully saying, 50 aliases are most > > definitely a smell! > > > > The recommended way to build a DSL is to check for existing steps. > > JBehave provides step finding functionality, which you may use in > > different run contexts, as usual. Brian has already pointed you toward > > the core doc page: > > > > http://jbehave.org/reference/stable/finding-steps.html > > > > (https://github.com/jbehave/jbehave-core/blob/master/examples/trader-spring/ > > sr > > c/main/java/org/jbehave/examples/trader/spring/TraderEmbedderWithSpringJUnit > > 4C > > lassRunner.java > > provides an example of how you can embed this functionality to run via > > JUnit in Eclipse). > > > > You may also find useful the web interface to this functionality, via > > the Web Runner: > > > > http://jbehave.org/reference/web/stable/using-web-runner.html > > > > The web functionality is earmarked for some improvements - notably > > auto-completion: > > > > http://jira.codehaus.org/browse/JBEHAVE-669 > > > > The WebRunner may be particularly useful if you have a separation > > between technical and non-technical team members. > > The technical team can provide a story running and finding context as a > > webapp, which the non-technical team can use without needing access to > > the code or the build system. > > > > Don't hesitate to let us know how you're getting on. > > > > We'll be glad to help. > > > > Cheers > > > > On 16/12/2011 15:52, Christian Taylor wrote: > > > Hi all, > > > > > > Just found and joined this group. Looks like a great resource for help > > > and sharing experiences:) > > > > > > I joined as a result of a specific discussion we are having about > > > scenario steps, as we are about to take the leap into the jBehave world > > > and need to try and understand things a little more in-depth before we > > > commit entirely. > > > > > > We are a small test team of 2 (sometimes 3), but many of the developers > > > also contribute to writing stories. We have a fairly defined divide > > > between authors and implementers - meaning it's so far only the dev > > > teams doing the implementation. That may change in the future, but it's > > > working well for us. > > > > > > Reading through the information available, there seems to be a lot of > > > focus on the implementations, but reading about the alias feature, my > > > toes curl at the thought of a test-suite building up and ending with 50 > > > aliases to 1 implementation. > > > > > > If I am about to embark on writing some new stories and want to make > > > sure that my steps use a syntax which is identical to the existing > > > stories so as to avoid the use of aliases - how is this done? > > > Is it simply a search through the exisiting .story files for the step I > > > have just written? > > > Is there a tool for eclipse or otherwise that aids this? > > > > > > Is it simply a fact of life that aliases are a necessary evil (in my > > > book at least)? > > > > > > Remember I'm referring only to the authoring of the scenarios here, and > > > not the implementation. > > > > > > Thanks > > > > > > Christian > > > > > > > > > --------------------------------------------------------------------- > > > 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 > > > --------------------------------------------------------------------- > 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
