Specflow - состояние между "сценариями" - PullRequest
3 голосов
/ 23 августа 2011

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

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

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

Опции, которые я рассмотрел:

  • Выполнить весь год по одному сценарию, включающему множество заданных, когда, а затем утверждений. В результате получается один огромный сценарий, который трудно читать.
  • Создатьконкатенация «дано» для каждого сценария.«Дано: все платежи за месяц X были сделаны». Это создает много трафика базы данных, так как каждый сценарий должен будет создавать и уничтожать тестовые данные.

Есть ли лучший способ хранениясостояние между сценариями и обеспечить выполнение сценариев в нужной последовательности?

1 Ответ

4 голосов
/ 23 августа 2011

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

В вашем случае данная часть должна подготовить данные для рассматриваемого вычисления, когда следует рассчитать, а затем проверить результат этого единственного вычисления.

Чтобы сократить время выполнения, возможно, вы могли бы попытаться выбрать «важные» сценарии таким образом, чтобы они тестировали различные аспекты. Вероятно, нет необходимости проверять каждый месяц 1-11. У вас может быть один тест для первой месячной заработной платы, один для 2-го месяца, один для закрытия всего года, один для начала нового года и т. Д.

Это также распространенная техника, которая не обязательно должна быть сделана так же, как "настоящее приложение" (с нуля). Иногда вы можете сделать ярлыки в тесте, чтобы обеспечить предварительные условия быстрее и проще. Например. Вы можете указать суммы за предыдущий месяц, если это все, что нужно вашему сценарию для расчета следующего месяца (вместо того, чтобы позволить приложению вычислять все с нуля). Конечно, вы должны знать, что вы делаете, и вы должны учитывать риск, связанный с подделкой некоторых аспектов приложения.

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