Должны ли все правила проверки проверяться в функции Cucumber?

В Ruby on Rails, если все правила проверки для данной модели проверяются в рамках спецификации этой модели (или модульных тестов), считается ли необходимым писать сценарий Cucumber для каждой проверки?

Достаточно ли вместо этого написать два сценария: один для ввода правильных данных и один для ввода неверных данных?


person Community    schedule 07.05.2011    source источник
comment
Прошу прощения, если это глупый вопрос - я все еще пытаюсь понять BDD.   -  person    schedule 07.05.2011
comment
Разделяю вашу точку зрения: в вашем случае достаточно двух огурцов.   -  person apneadiving    schedule 07.05.2011
comment
@apneadiving: Но представьте ситуацию, если вы создаете сайт оптовой электронной коммерции, где покупатель должен заказать не менее 10 единиц каждого товара. Эта проверка является важным бизнес-правилом и должна быть представлена ​​на уровне Cucumber.   -  person Andy Waite    schedule 07.05.2011
comment
@andy: вы определенно правы, представленный вами случай требует интеграционного тестирования.   -  person apneadiving    schedule 07.05.2011


Ответы (3)


Это хороший вопрос, и ответ таков: это зависит.

Вы можете думать о Cucumber как о способе общения между владельцем продукта, разработчиками и тестировщиками.

Если вы чувствуете, что наличие проверок в Cucumber способствует общему пониманию того, что делает продукт, оставьте их там.

Один из подходов состоит в том, чтобы объединить проверки в набросок сценария:

Scenario Outline: User tries to register but skips a mandatory field
  Given I am registering
  And I leave the "<field>" blank 
  When I click "Submit"
  Then I should see "<message>"
  And I should not be registered
    | field         | message                         |
    | Forename      | Please enter your forename      |
    | Surname       | Please enter your surname       |
    | Date of Birth | Please enter your date of birth | 
person Andy Waite    schedule 07.05.2011
comment
Это кажется хорошим компромиссом. Но как насчет разных типов проверки (уникальность, длина и т. д.) Нужна ли мне отдельная схема сценария для каждого типа? - person ; 07.05.2011
comment
Трудно сказать, не зная контекста. Не могли бы вы привести пример? - person Andy Waite; 07.05.2011
comment
Как насчет модели User, в которой имя пользователя должно быть уникальным и содержать только буквенно-цифровые символы, пароль должен состоять не менее чем из 6 символов, а адрес электронной почты должен быть действительным. Я думаю, что, поскольку проверки уже тестируются в спецификации модели, должно быть достаточно просто проверить два возможных результата в действии создания контроллера в функциях Cucumber, а именно, когда модель успешно сохраняется, а когда нет. . - person ; 07.05.2011
comment
Или, возможно, я полностью упускаю суть огурца - это тоже возможно: P - person ; 07.05.2011
comment
Хорошо, давайте возьмем пример пароля. Ваш владелец продукта заботится о том, чтобы минимальная длина составляла 5 символов или 6 символов? Я бы подозревал, что нет. Для него важно то, что это нелегко угадать или взломать. Решение о минимальной длине пароля, вероятно, должен принимать программист, так как у него будут знания и опыт, чтобы выбрать подходящую минимальную длину. Таким образом, минимальная длина пароля, вероятно, не должна быть раскрыта в функции Cucumber. - person Andy Waite; 07.05.2011
comment
@Энди Уэйт: Это очень хороший момент. Похоже, что тогда большинство проверок должны оставаться в спецификации модели. Большое спасибо за ваш вклад. - person ; 07.05.2011

Это отличный вопрос, и я занимаюсь им недавно.

В вашей организации это может быть по-другому, но в моей организации мы стараемся оставить проверочные тесты в полевых условиях модульным тестам или какой-либо другой структуре, которая лучше справляется с такими ситуациями. Кроме того, я придерживаюсь мнения, что Cucumber предназначен исключительно для автоматизированного приемочного тестирования (также известного как инструмент связи между вами/вашей командой и PO) — и что другие методы следует использовать для всего, что выходит за рамки этой области.

person Tyler Poland    schedule 08.05.2014

Зачем оставлять что-либо открытым для предложений? Допущение допущений, сделанных разработчиками, по своей сути рискованно с точки зрения создания переделок.

То, как каждое поле формы ведет себя в различных обстоятельствах (создание, отображение, редактирование, персонализация), явно является критерием приемлемости.

Если вы спрячете его в модульном тесте, вы отключите его от действующей документации.

Вам действительно не нужны модульные тесты, если вы действительно покупаете BDD.

Feature: Edit staff personal
  Scenario Outline: Form validation
    Given I am editing a staff personal details
    And the form contains a "<Mandatory?>" field with a label "<Label>"
    And text fields have a input length of between "<Min Length>" and "<Max Length>"
    And select fields have these "<Options>"
    When I submit the form by clicking the save button
    Then an error displays if validation fails
    But commits my changes if validation is successful and returns the form back to display mode
    Examples:
    | Label | Mandatory? | Type | Min length | Max length | Options
    | Title | true | select | 0 | 0 | Mr, Mrs, Miss, Ms, Dr, Prof |
    | Surname | true | text | 2 | 50 | null |
    | Forename | true | text | 2 | 50 | null |
    | Known as / Other Surname | false | text | 2 | 50 | null |
    | Known as forename | false | text | 2 | 50 | null |
    | Date of birth | true | date-picker | 0 | 0 | null |
    | NI number | true | ni-number | 0 | 0 | null |
person jenson-button-event    schedule 21.01.2020