Должны ли сценарии BDD включать фактические тестовые данные или просто описывать их?

Question

Мы подошли к моменту, когда мы поняли, что существует два варианта задания тестовых данных при определении типичного сценария CRUD:

Вариант 1: Опишите данные для использования, ипозвольте реализации определить данные

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have typed in a valid name
      And I have typed in a valid code
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the created region details

Вариант 2. Явно укажите тестовые данные для использования

Scenario: Create a region
    Given I have navigated to the "Create Region" page
      And I have filled out the form as follows
        | Label | Value  |
        | Name  | Europe |
        | Code  | EUR    |
    When I click the "Save" button
    Then I should be on the "Regions" page
     And the page should show the following fields
        | Name   | Code |
        | Europe | EUR  |

В терминах преимуществ и недостатков,мы установили следующее:

Вариант 1 прекрасно описывает случай, когда меняется определение «действительное имя».С этим может быть сложнее справиться, если мы перейдем к варианту 2, где данные испытаний находятся в нескольких местах.Вариант 1 явно описывает, что важно в данных для этого теста, особенно если это был сценарий, в котором мы говорили что-то вроде «набрал неверный номер кредитной карты».Он также «чувствует» более абстрактно и как-то BDD, будучи более заинтересованным в описании, чем в реализации.

Однако в Варианте 1 используются очень конкретные шаги, которые было бы сложно использовать повторно.Например, «страница должна показывать детали созданного региона», вероятно, будет использоваться только в этом сценарии.И наоборот, мы могли бы реализовать вариант 2 «страница должна показывать следующие поля» таким образом, чтобы его можно было многократно использовать в других сценариях.

Я также думаю, что вариант 2 кажется более удобным для клиента, поскольку ониМожно увидеть на примере, что происходит, вместо того, чтобы интерпретировать более абстрактные термины, такие как «действительный».Будет ли вариант 2 более хрупким?Рефакторинг модели может означать нарушение этих тестов, тогда как, если тестовые данные определены в коде, компилятор поможет нам с изменениями модели.

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

Спасибо!

Answer 1

Я бы сказал, это зависит.В некоторых случаях для успешного выполнения сценария может потребоваться большой объем данных.Часто большая часть этих данных не важна для того, что мы на самом деле тестируем, и поэтому становится шумом, отвлекающим от понимания, которого мы пытаемся достичь с помощью сценария.Я начал использовать то, что я называю шаблоном данных по умолчанию, чтобы предоставить данные по умолчанию, которые можно объединить с данными, относящимися к сценарию.Я написал об этом здесь:

http://www.cheezyworld.com/2010/11/21/ui-tests-default-dat/

Надеюсь, это поможет.

Answer 2

Я предпочитаю вариант 2.

Для бизнес-пользователя сразу ясно, что является входными данными и выходными данными. При использовании варианта 1 мы не знаем, что такое действительные данные, поэтому ваша реализация может быть неправильной.

Вы можете быть еще более выразительным, добавляя неверные данные, когда это уместно

Scenario: Filter for Awesome
    Given I have navigated to the "Show People" page
    And I have the following data
    | Name  | Value  |
    |  John | Awesome|
    |  Bob  | OK     |
    |  Jane | Fail   |
When I click the "Filter" button
Then the list should display    
    | Name   | Value   |
    |  John  | Awesome |

Однако вы должны хранить данные так, чтобы они описывались с точки зрения предметной области, а не конкретной реализации. Это позволит вам тестировать на разных уровнях в вашем приложении. например Пользовательский интерфейс и т. Д.

Answer 3

Каждый раз, когда я думаю об этом, я передумал. Но если вы думаете об этом - тест должен доказать, что вы можете создать регион. Критерии соответствуют обоим вариантам. Но я согласен, что визуальные подсказки с вариантом 2 и дружелюбие разработчика, вероятно, слишком хороши, чтобы отказаться. В подобных примерах, по крайней мере.