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

Feature: Add new voucher
   As a user I want to be able to add vouchers

Scenario Outline: Add new voucher with an invalid voucher
    Given a trip voucher <Voucher>
    When I access "/voucher" endpoint
    Then error message should be "Voucher is invalid"

Examples:
  |Voucher    |
  |ABCDEFG    |
  |1234567    |
  |invaL!Ds   |

Scenario Outline: Add a previously redeemed voucher
    Given a used voucher <Voucher>
    When I access "/voucher" endpoint
   Then error message should be "Voucher has already been used"

Examples:
  |Voucher        |
  |VALIDVOUCHER   |

Я работаю над созданием REST API на Go, одновременно учусь создавать интеграционные тесты на Java, потому что QA используют его для тестирования. Каковы лучшие практики здесь, на линии When I access x endpoint? Я знаю, что это произведет Duplicate step definition error. Следует ли мне изменить способ написания файла функций, или есть уловки Java, которые я упускаю.

0
Adam 24 Сен 2018 в 05:24

2 ответа

Лучший ответ

Я использую SpecFlow + .NET в данный момент на работе, и я также использовал jBehave + Java в прошлом.

То, что вы делаете, совершенно нормально и не должно вызывать ошибок. Фактически, одно из преимуществ наличия такой структуры Given-When-Then - это возможность повторно использовать фразы.

Что вам нужно быть осторожным, так это убедиться, что ваш шаг: Когда я получаю доступ к конечной точке «/ voucher»: должен соответствовать только одному методу Java в файле шагов. итак, что-то вроде:

@When("I access "/voucher" endpoint")
public void WhenIAccessVoucherEndpoint(){
// implementation of your step. may be make a Rest call.  
}

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

1
Praveen 24 Сен 2018 в 09:40

В вашем примере, если оба определения шагов вызывают одну и ту же конечную точку и выполняют одно и то же действие, то рекомендуется Re-Use определение шага.

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

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

Если у нас есть повторяющееся определение шага, есть вероятность, что вы получите сообщение об ошибке "matches more than one step definition".

Если вы по-прежнему хотите поддерживать две разные функции определения шагов и иметь разные реализации для каждой, рекомендуется изменить фразы

0
Praveen 24 Сен 2018 в 08:25