Сколько данных должно быть указано в файле характеристик огурца?

Я пытаюсь написать несколько файлов функций Gherkin, чтобы провести приемочное тестирование BDD с помощью SpecFlow. Система, которую я пытаюсь протестировать, состоит из нескольких RESTful API - система имеет микросервисную архитектуру. В сценарии мне нужно быть уверенным, что некоторые записи уже существуют в базе данных, прежде чем переходить к фактическому сценарию, поэтому я включил раздел Background с частью given. Проблема, с которой я столкнулся, заключается в том, что каждая из этих записей, которые должны существовать, создаются с помощью API-интерфейсов, которые требуют большого количества данных в их контакте схемы, и команда требует, чтобы я указывал все поля и их соответствующие значения в записи в корнишоне. Таблица. Результат примерно такой:

| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|

Это заголовок одной из моих таблиц, которая будет использоваться для создания записи Traveler в базе данных перед началом фактического тестирования по спецификации. Однако, как вы можете видеть, в этой таблице слишком много полей, и поэтому она слишком длинная, слишком умещается на экране, и поэтому ее очень трудно читать и поддерживать. во-вторых, он тесно связан со схемой DTO. Я утверждал, что мы не должны вдаваться в подробности наших спецификаций, пытаясь включить только важные высокоуровневые данные (например, учитывая, что у нас уже есть путешественник по имени «Джеймс Петерсон»), но команда и технический директор настаивали на том, чтобы эти детали были присутствует в файле функций. В следующей попытке я разбил таблицы на несколько таблиц (например, личные данные, данные заказа, паспортные данные и т. Д.).

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


cucumber bdd gherkin acceptance-testing
person Ashkan Taravati    schedule 30.01.2020    source источник
comment
Как насчет того, чтобы поместить все данные в файл, скажем, например .csv, и прочитать этот файл на шаге «Учитывая, что все записи из файла‹ example.csv ›существуют в БД»? Таким образом, вам не нужно помещать его прямо в файл функции.   -  person Mr Cas    schedule 31.01.2020
comment
@MrCas, это было бы хорошей идеей для уменьшения размера таблиц по вертикали и отделения фактических данных от файла функций. Но даже если я это сделаю, моя проблема все равно останется, потому что мне все равно нужно будет указать столбцы (поля). Имейте в виду, что разработчик, который пишет шаги для теста, должен будет использовать DTO для отправки фактических запросов к API.   -  person Ashkan Taravati    schedule 03.02.2020

Ответы (3)


arrow_upward
2
arrow_downward

Можете ли вы транспонировать поля и значения в таблице данных, как показано ниже.

      |field                 |values    |
      | PassportExpireDate   |[]        |
      | PassportNumber       |[]        |
      | PassportCountry      |[]        |
      | Firstname            |[]        |
      | Lastname             |[]        |
      | LocalFirstname       |[]        |
      | LocalLastname        |[]        |
      | Birthday             |[]        |
      | NationalNumber       |[]        |
      | NationalityCountryId |[]        |
      | PassengerType        |[]        |
      | Gender               |[]        |
      | PartyId              |[]        |
      | SourceTravelerId     |[]        |
      | CellNumber           |[]        |
      | Price                |[]        |

И на шаге def реализуйте логику для получения значений из массива values.

person supputuri    schedule 09.02.2020
comment
Дайте мне знать, если у вас возникнут какие-либо вопросы или вам понадобится помощь с этой реализацией. Единственная проблема - убедиться, что количество элементов массива одинаково для всех полей. - person supputuri; 09.02.2020

arrow_upward
0
arrow_downward

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

Scenario Outline: Add Traveler
    Given ...
    When  ....
    Then  ....

@source:TravelerRecordsExamples.xlsx
Examples:
| PassportExpireDate|PassportNumber|PassportCountry |Firstname|Lastname|LocalFirstname|LocalLastname | Birthday | NationalNumber | NationalityCountryId | PassengerType | Gender |PartyId | SourceTravelerId | CellNumber | Price|
person Anatoliy Sakhno    schedule 10.03.2020

arrow_upward
0
arrow_downward

TL; DR Нет

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

Затем используйте простые Гивенса, чтобы создавать свои вещи.

В вашем случае вы, кажется, создаете путешественников. Поведение, которое документирует ваш корнишон, создано путешественниками. КАК создаются путешественники и каковы их характеристики, нет места в этом описании поведения.

Так что ваши фоновые шаги станут чем-то вроде

Given there are foo travelers

Реализация похожа на

Given 'there are foo travelers' do
  create_foo_travelers
end

и теперь вы перевели свою задачу с

                     from

How do I do something incredibly stupid and difficult in Gherkin 

                      to

How do I write some code to create travelers

Это подход, который вы должны использовать для написания всех сценариев при Cuking. Сценарий должен только документировать ЧТО и ПОЧЕМУ поведение. Никаких подробностей о том, КАК реализовано поведение, нет места в сценарии.

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

person diabolist    schedule 19.03.2020