Gherkin A single feature for multiple roles

cucumber domain-driven-design bdd gherkin user-stories

681 просмотра

3 ответа

1911 Репутация автора

As my ubiquitous language I have some phrases like :

Feature : Display A Post
In order to be able to check mistakes in a post
As an admin or customer
I want to be able to view the post

Scenario : Display Post
When : I select a post
Then : the post should be viewed

Is that a right user story? Such scenarios may have some minimal differences at UI level. Should I violate the DRY principle and repeat the feature for another role?

Different users may need different requirements over time, and I think this is the reason we usually write user stories per the user role.So should I be worry about how the requirements may change over time for different roles or I can leave a single user story (and the same test code,production code, databse ...) with multiple roles and refactor when their requirements forced me to separate them ?

Автор: Mohsen Источник Размещён: 19.07.2016 05:52

Ответы (3)


2 плюса

4983 Репутация автора

I am not sure what your problem here and will try to guess. So first, your first three lines is just a description and not real steps. This enables adding custom text that will not run.

As to your other 2 steps, it is very hard to say whether they are good or not. As you might have already noticed, you are not bound by Cucumber to have a specific scenario flow. Cucumber gives you the freedom to design and write your code the way it makes more sense to YOU and YOUR business logic.

Saying that, I see no issue in repeating similar steps to test another role. In order to make the feature file a bit more DRY you can use the Scenario Outline option. It might look something like this:

Scenario Outline: Display Post as <role>
  When I select a post as <role>
  Then the post should be viewed

  Examples:
    |role |
    |role1|
    |role2|

In this case, two scenarios run one after another while rolevalue changes according to the Examples list.

Now, in regards to your possible changes in future. You can't always predict what will happen in future and unless continuously changing current requirements is a normal practice for you or your team, I wouldn't worry too much about this. If sometime in future current scenarios will become obsolete, you will review them and rewrite them or add new ones accordingly.

Автор: Eugene S Размещён: 19.07.2016 03:26

1 плюс

2603 Репутация автора

I think the problem here is your language which needs refinement to clarify what you want to do here and why its important.

It seems to me that as an admin looking to fix mistakes in a post that what I need to is to be able to change a post.

A similar thing applies for the customer (should that be author?). If you explore what they will do when a post has been authored with a mistake then you will probably find that different roles interact in different ways. You'll start to ask questions about what happens if the customer and the admin make fixes, and how the customer responds when the admin makes a fix that the customer doesn't like and all sorts of other scenarios.

If you do this you'll probably find that most of your duplication goes away, and you'll learn lots about the differences between customer and admin behaviour in this particular context.

Автор: diabolist Размещён: 20.07.2016 04:24

2 плюса

21 Репутация автора

If multiple roles are required in a feature, then that means it is an epic, not a feature. It is a must to break down each feature so it only has one role, and it can deliver a single value to a single group of users.

Автор: Reid Lai Размещён: 22.07.2017 02:37
Вопросы из категории :
32x32