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

Мы пришли к выводу, что при определении типичного сценария 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 более хрупким? Рефакторинг модели может означать нарушение этих тестов, тогда как если тестовые данные определены в коде, компилятор поможет нам с изменениями модели.

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

Спасибо!

Ответ 1

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

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

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

Ответ 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 |

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

Ответ 3

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