Как лучше всего хранить ответы REST API в Cucumber? - PullRequest
0 голосов
/ 07 января 2019

Я собираюсь построить тесты e2e для моего RESTful API и использовать для этого Cucumber. Я также собираюсь использовать cucumber-spring, чтобы разделить состояние между StepDefs.

Давайте предположим, что RESTful API - это про зоопарк Вот несколько сценариев ниже.

  • клиент регистрируется на сайте зоопарка с логином / паролем. Мне нужно хранить идентификатор клиента в государстве. Также мне нужно сохранить полный http-ответ для регистрации, так как я хочу иметь возможность проверить, что если клиент предоставляет слишком слабый пароль, http-ответ содержит правильный http-код состояния.
  • покупатель покупает билет в зоопарк. Мне нужно сохранить идентификатор билета и ответ, по тем же причинам.

Хорошо, пока все просто. Но что, если:

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

  • другой клиент регистрирует и покупает билет, поэтому я хочу убедиться, что зоопарк не переполнен. Здесь тот же вопрос, что и выше - какое определение мне следует использовать и какую переменную состояния?

Ответы [ 2 ]

0 голосов
/ 08 января 2019

Простое решение состоит в том, чтобы не пытаться повторно использовать определения шагов так часто. Одна из самых больших ошибок, которую люди делают с Cucumber, - это попытаться многократно использовать определения шагов. На самом деле совсем не важно, сколько у вас определений шагов, если в ваших определениях шагов используются вспомогательные методы.

в рубине, но я уверен, что вы можете перевести

When 'I buy a ticket' do 
  @ticket = buy_ticket
end

When 'I buy a second ticket' do
  @second_ticket = buy_ticket
end

When 'I buy a discounted ticket' do
  @discount_ticket = buy_ticket
end 

When 'I buy a family ticket' do
  @family_ticket = buy_ticket
end

Теперь остальная часть вашего сценария может говорить о second_ticket или family_ticket.

Примечание: здесь нет дублирования, все шаги вызывают один и тот же метод для создания заявки (вы можете использовать параметры для обработки и дополнительную сложность, которую может потребовать buy_ticket).

0 голосов
/ 07 января 2019

Фреймворк NoraUi делает это классной жизнью (https://github.com/NoraUi/NoraUi/blob/master/src/main/java/com/github/noraui/utils/Context.java).

Вы можете использовать этот механизм для хранения переменных в контексте. Затем можно сбросить контекст для каждого сценария (или для каждого example в случае Scenario Outline).

public static void saveValue(String key, String value) {
    getInstance().scenarioRegistry.put(key, value);
}

public static String getValue(String key) {
    return getInstance().scenarioRegistry.get(key);
}

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

Context.saveValue(targetKey, targetStringValue);

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

String value = Context.getValue(textOrKey) != null ? Context.getValue(textOrKey) : textOrKey;
...