Огурец для REST, запись файла функции при наличии повторяющихся шагов

Question

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

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, которые я упускаю.

Answer 1

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

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

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

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

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

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

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