How to test filters based on authorization using G

Question

I don't understand how should scenario look like when there is no actual business action to test something.

Is the following scenario good enough? I don't understand how it can be converted into Past, Action, Future sequence.

Scenario:
    Given The system contains the following users
        | email             | role  |
        | [e-mail] | ADMIN |
        | [e-mail]  | USER  |
    And The system contains the following Products
        | Name     | Active |
        | Product1 | true   |
        | Product2 | false  |

    Then The list of Products for '[e-mail]' user should contain the following entries
        | Name     | Active |
        | Product1 | true   |
        | Product2 | false  |
    And The list of Products for '[e-mail]' user should contain the following entries
        | Name     | Active |
        | Product1 | true   |

Answer 1

Personally, this is how I would write that scenario:

Scenario Outline: Viewing inactive products in different roles
    Given I am logged in as <user_role>
     And the system contains the active product "product1"
     And the system contains the inactive product "product2"
    When I view the available products
    Then I should see the "product1" product
     And I <should_see_inactive?> see the "product2" product

 Examples:
   | user_role  | should_see_inactive? |
   | an admin   | should               |
   | a user     | should not           |

What you seem to be testing here, is whether or not a particular user in a role has the right level of access to view the inactive products.

Your statements are written in a way that seems that 2 scenarios should be written, and as you're testing the same thing for 2 different user groups to show the differences I'm using the Scenario Outline

Answer 2

tl;dr

Communication if figgin hard. Embedding behavior (ie a "when" clause) into the requirements is better (IMO).

Your posted suggestion requires interpretation

Your posted suggestion actually doesn't tell me what the requirements are! Instead, I have to now figure out what the underlying intent must be in order to get what you're after. In other words, I have to "reverse engineer" the intended logic. That is a worse way to communicate requirements. In fact, it's a worse way to communicate anything complex.

Here's one interpretation of your posted suggestion

Given a user who is not an admin
And products which are not active
When that user ever views any products
Then he cannot view the inactive products

Given a user who is an admin
And products which are not active
And products which are active
When that user ever views any products
Then he can view the both sets of products

However, in your posted suggestion, should the non-admin be allowed to view inactive products? This is a legitimate question.

If the only thing you say is that certain products are "for" so-and-so, then I don't know if you mean "ownership" or "viewability." What if I wrote code that allowed all users to view everyone else's products? If you click an admin user profile, you see all products. If you click on a non-admin user profile, you only see active products. See? I have successfully curated lists for each user according to your requirements. But what if your intent was security based! That somehow a non-admin should never even see those products existing in the UI at all. That is a very different requirement, but your writeup doesn't distinguish it. Here's another good interpretation: What if the only thing you're wanting me to filter is some kind of "selectibility"? ie: I can view all products, but I cannot select/attach/use inactive products (unless I'm an admin). Again, this is a different interpretation to curation and visibility.

You might claim that "context" makes that obvious. Given the page flow of the app, no one's going to misunderstand the intent. However, after you see enough programs undergo major changes, you will value not depending on "context" to make things "obvious." Or what is someone merely splits your gherkin file into two parts. If surrounding requirements was necessary to interpret this one correctly, then now we've lost that simply by improving file structure in the code.

In short, communication if figgin hard. I believe embedding behavior into the requirements decreases the chances that people will misinterpret it.

Why I prefer my suggestion (which has a "when" clause)

In contrast, the suggestion in this answer is literal. It doesn't matter what other layers of permissions are added or changed later or how the DB schema changes, we know what the requirement is.

I think behavior driven requirements helps you communicate with your product owner better too. I'm betting the product owner would say "I don't want anyone else (other than admins) being able to see inactive products." My suggestion is almost verbatim what the product owner would say in that case. Your suggestion has to "translate" the real intent to the "data-driven" view a programmer likes to think in. However, the more we "translate" their comments into different formats (like data structure diagrams) the more we risk assumptions and misunderstanding. Such translations are "lossy." The more times throughout our careers we hear our product owners say "what? That's not what I said!" the more we will feel uncomfortable with "implicit" communication or "obvious" translation of the requirements. Instead, explicitly state every single literal requirement.

In my experience, product owners always think in more behavior/customer-driven terms first. That's just my experience though.

About Gherkin

Gherkin is merely a tool, so it does one thing and one thing well: it forces you to think in behavior driven development (BDD). If you use gherkin, you must write things in terms of "input" behavior and it's required outcomes. Otherwise you're using the wrong tool.

Instead, you should decide if you think BDD is a good philosophy to force yourself to follow. If you think following that philosophy is good, then you will need to keep rephrasing the requirement until there's a "when" statement. That exercise of forcing yourself to make a "when" statement is believed to be good by some (including me).

Also, gherkin is not mutually exclusive to other documentation. For example, you'll still have ERD diagrams, UI mockups, etc. In fact, you could even reference gherkin scenarios from within your other design docs. Gherkin is meant to help you know if you are doing what the customer asked, not if you are designing the code well. Other specs do that, and they work together.

Not only that, but "requirements" themselves have layers and are represented in different mediums. For example, you might need a "sign-off" document that the product owner writes up for the customer. The format of that document is very different than gherkin, and is good because of that. On the other extreme, you have an ERD diagram. I see gherkin as "in between" those levels of requirement abstraction.

Also, regression testing should be made easy. With gherkin, you could even go so far as to automate it. Yet, again, with your posted suggestion I would fear that regression testers have to infer and figure out what cases to test. And that's a horrible way to do regression testing. Every single case should be spelled out. Even if it's "obvious" to you, I guarantee it's not obvious to others (and vice versa). Plus, even for yourself, if you have to do regression testing, then you want things to be easy. The more stressful regression testing is, the less likely it will happen and the less well it will be done. Having explicit checklists makes it less stressful and easier to follow. And being behavior driven aligns perfectly with regression testing.