Trying to perfect my cucumber scenarios

Question

I know either of these will work, but I am trying to become a better member of the ruby/cucumber community. I have a story that tests if multiple sections of my website doesn't have any links under it, it should not display. So which of these two ways are the best ways to write the scenarios. Once again, I understand either will work but i'm looking for the Best Practice solution. I would normally use option B as they are all testing different "Then" steps; however I have been some research and I'm second guessing myself since I can test all the scenarios with the same given statement and I was reading you should only make a new scenario if you are changing both the "given" and "then" steps.

A.

Scenario: A user that cannot access A, B, C, or D
    Given I am a, user without access to A, B, C, or D
    When I navigate to reports
    Then I see the A header
    But I cannot click on A's header
    And I see error message under A stating the user does not have access
    And I do not see the B section
    And I do not see the C section
    And I do not see the D section

OR

B.

Scenario: A user that cannot access A
    Given I am a, user without access to A
    When I navigate to reports
    Then I see the A header
    And I see error message under A stating the user does not have access
    But I cannot click on A's header

Scenario: A user that cannot access B
    Given I am a, user without access to B
    When I navigate to reports
    Then I do not see the B section

Scenario: A user that cannot access C
    Given I am a, user without access to C
    When I navigate to reports
    Then I do not see the C section

Scenario: A user that cannot access D
    Given I am a, user without access to D
    When I navigate to reports
    Then I do not see the D section

Answer 1

I believe best practice is to break down features into their various parts (in this case, scenarios)

Option B is better because it adheres to the single responsibility principle (which of course can be applied to many different parts of code). The way B is written is clear and direct. If you come back to this in 6 months, or a new developer sees this for the first time, you both have a good idea of the goal of the test.

Option A seems to be doing a lot, and although this is an integration test, you should keep the specific parts of code being tested as independent as possible. Ask yourself this, when this test fails, will you know exactly why? or will you have to start digging around to see what part of the test actually failed?

Best practice, in this context, advocates smaller sections of code. If these tests start repeating themselves (DRY, don't repeat yourself), you can start to refactor them (with a Background perhaps)

Answer 2

Granular scenarios are preferable because they communicate the desired behavior more explicitly and provide better diagnostics when there is a regression. As your application evolves, small scenarios are easier to maintain. Long scenarios develop a "gravitational attraction" and get even longer. In a long scenario, it is difficult to figure out all of the setup and side-effects of the steps. The result is an "gravitational attraction" where long scenarios keep growing.

A scenario outline can give make your test both granular and concise. In the following example, it's obvious at a glance that resources B, C, and D all have the same policy, while resource A is different:

Scenario Outline: A user cannot access an unauthorized resource
    Given I am a user without access to <resource>
    When I navigate to reports
    Then I do not see the <resource> section

    Examples:
        | resource |
        | B        |
        | C        |
        | D        |


Scenario: A user that cannot access A
    Given I am a, user without access to A
    When I navigate to reports
    Then I see the A header
    And I see error message under A stating the user does not have access
    But I cannot click on A's header

Answer 3

I would replace A B C or D for something more readable, just think that your grandma needs to understand this definition, she wouldn't understand what A B C D mean. so let's put it this way

given a basic user .. .. then the user cannot see the edit tools

given a super user .. .. then the super user should see the edits tools

Just try to join those A B C D in something meaningful such a group name, level n, team, etc

then you will use TestUnits for one of each items: A B C D if you will