Organising JBehave stories

We've just started looking at using JBehave for acceptance tests and I was wondering how people that are using it are organising the writing of stories and the storage of story files. It's just development that are working on them at the moment so we have the story files stored in the resources folder alongside the Java code to implement them.

I guess my actual ques开发者_运维知识库tion is how and where are you storing your story files and how does this work with the product owner or QA writing stories?

@MrWiggles
as t0rx told you are lucky to have QA to write stories/scenarios.
coming to your question:
Behaviour-Driven Development encourages you to start defining the stories via scenarios that express the desired behavior in a textual format.
JBehave Stories you can run by configuring in Maven (pom.xml).

You can make a folder for storing your story files in your package structure, like below:

Your_Project
      |
      |
      |--Source_Code
      |
      |--Stories
      |
      |--Testing
      |
      *pom.xml

By configuring your stories in maven, every time you build project it will give result with succeeded and failed stories/scenarios results.
QA will update the scenarios in the folder Stories, and the developer will implement the scenarios step by step by omitting existing steps (which are already developed and came in other scenarios).
QA simply run the scenario/story and he will find out the result in a textual (understandable) format.
Like below:

Some of the JBehave features concentrate on easy organizing.

• Annotation-based configuration and Steps class specifications
• Dependency Injection support allowing both configuration and Steps instances composed via your favourite container (Guice, PicoContainer, Spring).
• Extensible story reporting: outputs stories executed in different human-readable file-based formats (HTML, TXT, XML). Fully style-able view.
• Auto-generation of pending steps so the build is not broken by a missing step, but has option to configure breaking build for pending steps.
• Localisation of user stories, allowing them to be written in any language.
• IDE integration: stories can be run as JUnit tests or other annotation-based unit test frameworks, providing easy integration with your favourite IDE.
• Ant integration: allows stories to be run via Ant task
• Maven integration: allows stories to be run via Maven plugin at given build phase

If you are lucky enough to have the product owner or QA writing stories then you probably want them in a specific area of your source code repository so you can control access independently from your main source (and also give you more flexibility with when CI builds are triggered if you're doing that).

You'll likely find a lot of back-and-forth to minimise the number of new steps the devs have to write (i.e. stop them using ten different ways to write the same step), so will also need to run with pending steps not failuring the scenario (which is the default out of the box).

An alternative approach is that QA/product owner send scenarios to the devs who then cleanse them before adding to source control, but this puts effort back on the devs.