Сколько данных следует указать в файле объектов огурца? - PullRequest
Новая
       77

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

1 голос
/ 30 января 2020

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

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

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

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

Ответы [ 3 ]

2 голосов
/ 09 февраля 2020

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

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

И в шаге def внедрите logi c, чтобы получить значения из массива значений.

0 голосов
/ 20 марта 2020

TLDR Нет

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

Затем используйте простой Givens для создания ваших вещей.

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

Таким образом, ваши фоновые шаги становятся чем-то вроде 

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

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

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

0 голосов
/ 11 марта 2020

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|
...