Использование SpecFlow для сквозного регрессионного тестирования - PullRequest
8 голосов
/ 13 декабря 2011

Мы используем BDD и используем SpecFlow для управления нашей разработкой (ATDD).

Наша команда QA хотела бы определить свои собственные сквозные регрессионные тесты (в Gherkin / SpecFlow) и повторно использовать уже определенные нами шаги.

(Обратите внимание - я знаю, что это не очень хороший пример, но он должен предоставить достаточно подробностей)

Тест может включать в себя ..

  1. Войти
  2. Поиск товара
  3. Выберите продукт для покупки
  4. Создать заказ
  5. Выберите вариант доставки.
  6. Отправить заказ.
  7. Отменить заказ.

Это предполагает сценарий, подобный ..

Учитывая, что я вошел в систему
Когда я ищу продукт
И я выбираю товар для покупки
И я создаю заказ
И я выбираю способ доставки
И я отправляю заказ
И я отменяю заказ
Тогда ?? !!

Что явно неверно, поскольку мы не проверяем вывод на каждом шаге.

Так что может быть разрешено как последовательность сценариев:

Сценарий 1:
Учитывая, что я вошел в
Когда я ищу продукт
Тогда я вижу список продуктов

Сценарий 2:
Когда я выбираю продукт для покупки
Тогда я могу создать заказ

Сценарий 3:
Когда я создаю заказ
И я выбираю способ доставки
Тогда я могу отправить заказ

и т. Д. И т. П.

Основная проблема в этом заключается в том, что, похоже, нет способа указать порядок / последовательность выполнения сценариев (характеристика nUnit?). Поскольку между сценариями существуют зависимости (они не установлены на известную отправную точку), они должны выполняться последовательно.

Мои вопросы:

а) Мы пытаемся втиснуть квадратный колышек в круглое отверстие ?!

б) Кто-нибудь знает, есть ли способ использовать SpecFlow / Gherkin таким образом?

в) Или кто-нибудь знает, какие есть альтернативы?

Большое спасибо!

1 Ответ

11 голосов
/ 14 декабря 2011

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

Если вы хотите написать тестовые сценарии, то вы на правильном пути ... но поддерживать его будет страшным кошмаром, в первом случае (длинный сценарий) будет очень хрупким, а во второмВ случае (несколько сценариев) необходимо обеспечить определенный порядок выполнения.Оба они обескуражены и считаются анти-паттернами.

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

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

Given I am logged in
When I Search for a product
  And I Select a product to buy
  And I Create an order
  And I Select delivery option
  And I Submit the order

вы пишете что-то вроде

When I submit an order for product 'Canned beans'

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...