Which are good practices for writing/organizing JBehave stories?

Question

We have a lot of JBehave stories in our project (Java, Selenium). Sometimes there are steps in different stories which are the same grammatically, but has different logic behind. For example step:

When saves data

in one story means simply clicking Save button, but in another situation more complex behavior behind it is needed. It is possible to define these steps differently in stories, something like:

When saves Employee data
When clicks Save button and confirms save

but in big project there are a lot of stories and it is hard to edit stories like these. Also sometimes business people are against such story modification. Can you suggest some best practices or code examples in situations like these? May be it is technically possible to define test scope - like these will be stories and methods for Employee screen, but these are for Projects screen? Or there are some other ideas how to deal with this?

Additional information: now tests are organized in folders, something like suggested here: Organising JBehave stories, but they are treated by setup as one. Setup is pretty similar to these: http://jbehave.org/reference/stable/developing-stories.html#configuring

Answer 1

Generally, if the user can tell the difference then the automation should be able to do the same.

Use your automation tool to look for something that will show you which context you're in. For instance, if you have two screens, one for "Contacts" and one for "Employee Data", look for that text and you'll know which screen you're on. Alternatively you could look at the URL, or include a specific, hidden identifier that the automation tool will find.

This is similar to the "IsPurchased()" step here (I'm using a DSL rather than JBehave, and it's C#, but the principle is the same). If you actually look at the code for that step, you'll see that I look for a payment type, and if there isn't a valid one selected, then I select one.

In your case, your context is a bit bigger than a radio button; it's a whole page. I suggest that you separate the "Contacts" steps from the "Employee Data" steps, and from the "Shared" steps, and call whichever one is appropriate for your context.