Должны ли ваши спецификации BDD быть отделены от ваших тестов пользовательского интерфейса?

Question

Вчера я пошел на отличную презентацию Гойко Адзич о BDD.Возможно, я пропустил одну или две вещи, которые он сказал, поэтому вот один вопрос, который, я надеюсь, кое-что прояснит для меня.

Часто, когда вы видите пример BDD в Интернете, они включают шаги в пользовательском интерфейсе.На языке корнишона часто можно увидеть что-то вроде:

Scenario: Successful booking
    Given I am on the page ...
    When I enter the following ...

или что-то в этом роде.

Мой вопрос: действительно ли это связано с BDD?Не следует ли BDD ориентироваться на домен, и тогда у вас есть такие тесты, как пользовательский интерфейс или регрессионные тесты.Я думаю о том, чтобы использовать подобный синтаксис gherkin для описания системы бронирования:

BDD Spec:

Scenario: Successful booking
    Given I am an authenticated user
    When I place an order with the following items
        | item  | price ($) |
        | book1 | 5         |
    Then I should expect to pay $5
    And I should get a confirmation mail of my order

Обратите внимание, что я вообще не использую пользовательский интерфейс, ятолько описание того, как работает домен, и этот тест должен выполняться при каждой сборке.Затем вы можете пройти тест UI (также корнишон):

Scenario: Successful booking
    Given I am logged in on the site
    And I go to the page for item book1
    And I click add to basket
    Then I should have a basket with 1 item and $5
    When I click checkout
    Then I should get to the checkout page

, и он будет продолжен, возможно, его следует разделить на два или три сценария, но это не главное.Эти тесты тяжелее для запуска и, вероятно, должны выполняться только на ночных сборках.Суть вопроса по-прежнему такова: если вы отделите свои спецификации BDD от своего пользовательского интерфейса / регрессионного теста.

Answer 1

BDD сводится к сотрудничеству между QA другими нетехническими людьми с разработчиками, использующими родной язык в качестве определений для функциональности.Таким образом, с этой точки зрения оба ваших примера, вероятно, будут восприняты заинтересованными сторонами как особенность.

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

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

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

Answer 2

Не рекомендуется пытаться разделить тесты домена и пользовательского интерфейса.

Большое преимущество использования Cucumber заключается в том, что ваши спецификации (тесты) могут быть прочитаны и поняты нетехническими заинтересованными сторонами.Эти люди, вероятно, не слишком заботятся о деталях пользовательского интерфейса.

Так что хорошим подходом является просто протолкнуть материал пользовательского интерфейса вниз на уровень в пределах определений шагов, например

Given /^I place an order for "([^"]*)"$/ do |item|
  visit catalog_url
  click_link item
  click_button "Add To Basket"
  click_button "Submit Order"
end