Структура пользовательских историй [например, BDD]

Question

В настоящее время я много думаю о том, как структурировать лучшие истории пользователей, в моем случае это когда я использую подход BDD - напишите истории пользователей в начале dev.

Предположим, у нас есть следующие «новые функции»: настройки регистрации и учетной записи. В системе анонимны, аутентифицированы (обычные пользователи, которые вошли в свою учетную запись) и пользователи-администраторы (продвинутые пользователи) в качестве ролей.

Анонимный пользователь является единственным, кому разрешено регистрироваться, но не разрешено использовать функцию настроек, аутентифицированный пользователь может обновить свои настройки, и администратор может обновить свои настройки и дополнительные данные, но оба не могут зарегистрироваться (снова) ,

Каков наилучший способ структурирования функции - которую могут использовать разные роли, но не все по-другому - или функция, которая может использоваться только одной ролью в истории пользователей bdd?

Answer 1

Я верю, что вы ищете, это схема сценария.

Вы, кажется, пытаются добиться чего-то вроде этого:

@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'); 
      } 
     } 
    } 
} 

Это должно сделать это, и я надеюсь, что это помогает ,

Вы можете разделить настройки и ссылки на два различных файлов, если вы хотите структурировать его по-разному

Answer 2

1) «Как [роль]» является не об роли доступа, но кто требует особенность. В основном, некоторые заинтересованные стороны требуют функций, чтобы компания могла извлечь выгоду и улучшить бизнес.

2) Разный доступ должен описываться более сценариями в одном файле характеристик. Однако все ваши роли доступа не имеют решающего значения для объяснения этой функции. Несмотря на то, что инструменты, стоящие за Gherkin, могут протестировать, особенности и сценарии Gherkin - это больше о том, чтобы запечатлеть идею, чем охватывать все возможные сценарии. Выберите один положительный сценарий для покрытия каждой функциональности, а остальные - более низкие уровни тестирования, в основном модульные тесты.

Попытайтесь иметь в виду тестовую пирамиду, где приемочные испытания имеют лишь малую часть всех испытаний.