JBehave supports the idea of story mapping
http://jbehave.org/reference/stable/story-mapping.html
It doesn't quite do what you want (as I understand it) but we can quite
easily extend it.
Please raise jira issues with the requested features.
On 19/12/2011 11:27, Christian Taylor wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
