I am currently thinking a lot about how to structure best user stories, in my case its when I'm using the BDD approach - write User stories at the beginning of the dev.
Let's assume we have the following "new features": a registration and account settings. In the system are anonymous, authenticated (normal users that are logged in their account) and admin users (advanced users) as roles.
An anonymous user is as the only one allowed to register but not allowed to use the settings feature, an authenticated user can update its settings and an admin can update his settings and additional stuff but both can't register (again).
What is the best way to structure a feature - that may be used by different roles but not all in a different way - or a feature that may only be used by one role in bdd user stories?
I believe what you are looking for, is a Scenario Outline.
You seem to be trying to achieve something like this:
@javascript
Feature: When I am not logged in, I should not be able to access certain pages within the site
Rules:
- Logged in users should be able to see pages that users not logged in should not.
- Logged in users should not be able to follow a link to the registrations screen
Scenario Outline: Following links to the registrations screen.
Given I go to "<urlwithlink>"
And I click on "<link>"
And wait "(Insert time to wait for page to load here)"
Then the url should match "(Insert registrationsPage)"
Examples:
|urlwithlink|link|
(Put some examples here)
Scenario Outline: When I am logged in, I should not be able to follow those links
Given I am logged in as a user
And I go to "<urlwithlink>"
Then I should not see "<link>"
Examples:
|urlwithlink|link|
(Insert same examples as above)
Scenario: When I am not logged in, I should not be able to access the settings screen
Given I go to "(Insert where link to settings is, here)"
And the "(link to settings)" should be disabled (or use I should not see an "(link to settings)" element)
Scenario: When I am logged in, I should be able to access the settings screen
Given I am logged in as a user
And I go to "(Insert where link to settings is here)"
Then the "(link to settings)" should not be disabled (or use I should see an "(link to settings)" element)
If you would like the extra steps for your context:
/**
* @Then /^(?:|I )click (?:on |)(?:|the )"([^"]*)"(?:|.*)$/
*/
public
function iClickOn($arg1)
{
$findName = $this->getSession()->getPage()->find("css", $arg1);
if (!$findName) {
throw new Exception($arg1 . " could not be found");
} else {
$findName->click();
}
}
/**
* Simply wait the period of time.
*
* @Given /^(?:I |)(?:wait|pause for|take a break for) "([^"]*)"(?:|.*)/
* @param int $milliseconds
*
*/
public
function wait($milliseconds)
{
$this->getSession()->wait($milliseconds);
}
/**
* @Then /^(?:|the |an? )"([^"]*)" (?:|element )(?:is|should)(?P<negate>(?:n\'t| not)?) (?:|be )disabled$/
*
* @param string $elementCSS
* @param string $negate
*
* @throws Exception
*/
public function theElementShouldBeDisabled($elementCSS, $negate)
{
{
$page = $this->getSession()->getPage();
$element = $page->find("css", $elementCSS);
if (!$element) {
throw new Exception($elementCSS . ' does not exist');
}
$attributeValue = $element->getAttribute("disabled");
if (is_numeric(strpos($negate, ' not')) || is_numeric(strpos($negate, 'n\'t'))) {
if ($attributeValue) {
if (is_numeric(strpos($attributeValue, "disabled"))) {
throw new Exception('The element ' . $elementCSS . ' is disabled');
}
}
} else {
if (!$attributeValue) {
throw new Exception($elementCSS . ' does not have a disabled attribute');
} else if (!is_numeric(strpos($attributeValue, "disabled"))) {
throw new Exception('The element ' . $elementCSS . ' is not disabled');
}
}
}
}
That should do that, and I hope this helps.
You may want to split the settings and the links into two different files, if you want to structure it differently
1) The "As a [role]" is not about an access role but who requires the feature. Mostly, it's some stakeholder who requires features so that the company can benefit and do better business.
2) Different access should be described by more scenarios in the same feature file. However, all your access roles are not crucial to explain the feature. Despite the fact that tools behind the Gherkin can test, Gherkin features and scenarios are more about capturing the idea behind them than cover all possible scenarios. Choose 1 positive scenario for covering each functionality and the rest lay down to lower testing levels, mostly unit tests.
Try to keep in mind the test pyramid where acceptance tests have only a small part of all testing.