Структура пользовательских историй [например, в BDD]
В настоящее время я много думаю о том, как структурировать лучшие пользовательские истории, в моем случае, когда я использую подход BDD — писать пользовательские истории в начале разработки.
Предположим, у нас есть следующие «новые функции»: регистрация и настройки аккаунта. В системе присутствуют анонимные пользователи, прошедшие проверку подлинности (обычные пользователи, вошедшие в свою учетную запись) и административные пользователи (опытные пользователи) в качестве ролей.
Только анонимный пользователь может зарегистрироваться, но не может использовать функцию настроек, аутентифицированный пользователь может обновить свои настройки, а администратор может обновить свои настройки и дополнительные материалы, но оба не могут зарегистрироваться (снова).
Каков наилучший способ структурировать функцию, которая может использоваться разными ролями, но не всеми по-разному, или функцию, которая может использоваться только одной ролью в пользовательских историях bdd?
Решение
Я считаю, что то, что вы ищете, это набросок сценария.
Вы, кажется, пытаетесь достичь чего-то вроде этого:
@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)
Если вам нужны дополнительные шаги для вашего контекста:
/**
* @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');
}
}
}
}
Это должно сделать это, и я надеюсь, что это поможет.
Вы можете разделить настройки и ссылки на два разных файла, если хотите структурировать их по-разному.
Другие решения
1) «Как [роль]» не о роли доступа, а о том, кому нужна эта функция. В основном, заинтересованным сторонам требуются функции, чтобы компания могла получать выгоду и вести более эффективный бизнес.
2) Различный доступ должен быть описан несколькими сценариями в одном и том же файле функций. Однако все ваши роли доступа не имеют решающего значения для объяснения этой функции. Несмотря на то, что инструменты, стоящие за Gherkin, могут тестировать, функции и сценарии Gherkin больше связаны с воплощением идеи, лежащей в их основе, чем охватывают все возможные сценарии. Выберите 1 положительный сценарий для охвата каждой функциональности, а остальные перейдите на более низкие уровни тестирования, в основном модульные.
Старайтесь иметь в виду тестовую пирамиду, где приемочные тесты занимают лишь небольшую часть всех испытаний.