Правильный способ взаимодействия с веб-сервисом RESTful с использованием Cucumber - PullRequest
Новая
       4

Правильный способ взаимодействия с веб-сервисом RESTful с использованием Cucumber

0 голосов
/ 24 октября 2010

Я использую Cucumber для тестирования сквозного поведения приложения в моем веб-сервисе на Rails.В настоящее время у меня есть набросок сценария, который выглядит следующим образом (здесь я создаю гипотетический сценарий создания пользователя с другим пользователем): 

  Scenario Outline: Create a user with another user
    Given I want to create a user as a user "<user>"
    When I create a user with name "<name>"
    And the user's age is "<age>"
    Then then the response should be "<response>"

Scenarios: Create user with 3 args
  | user  | name            | age              | response                    |
  | bob   |  joe            | 25               | <some_xml_response>         |

У меня возникли некоторые затруднения с пониманием того, как мне следует писатьопределения шагов для этого плана.По сути, в настоящее время я объединяю блоб XML (для name + age) и мне нужно сделать что-то похожее на то, как использует rspec: post для отправки на контроллер и просмотра ответа.Мои определения шагов в настоящее время выглядят так: 

Given /^I want to create a user with another user "([^"]*)"$/ do |user|
  @reqxml << "<user><creator>#{user}</creator>"
end

When /^I create a user with name "([^"]*)"$/ do |name|
  @reqxml << "<name>#{name}</name>
end

And /^the user's age is "([^"]*)"$/ do |age|
  @reqxml << "<age>#{age}</age>"
end

Then /^then the response should be "([^"]*)"$/ do |response|
 # ?? not sure if I can use rspec :post here?
end

Как лучше всего улучшить этот контур огурца?У меня есть еще много чего я хочу проверить.В rspec это довольно просто, и, возможно, правильный ответ - вставить это в RSpec.Но я действительно хочу лучше использовать Cucumber и получить лучшую "большую" картину с тестированием истории конечного пользователя, такой как приведенное выше.

Ответы [ 2 ]

1 голос
/ 24 октября 2010

Я использую capybara / rspec / cucumber и pickle для согласования, чтобы минимизировать фактическое количество определений шагов, которые я должен написать, и, как правило, оно выполняет свою работу.

Pickle делает шаги, такие как «Учитывая, что модель существует с», автоматически доступными, веб-шаги Capybara заботятся об автоматизации браузера, такие как «goto route», или также предоставляют функции css и xpath для проверки вывода с помощью таких шагов, как « содержать "и т.д ....

Таким образом, вы можете протестировать весь свой стек, что является своего рода точкой огурца

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

Твои шаги с огурцом тоже немного изогнуты. «Данный» описывает ранее существовавшие условия, а не ваши цели. «Когда» должно описывать действия, которые вы предпринимаете для создания пользователя, а «Затем» должно проверять, что предпринятые действия повлияли на вашу цель.

0 голосов
/ 01 августа 2012

Хотя я видел, как это делается, тестирование API с огурцом сопряжено с особой болью.

Если ваш API действительно спокойный, написание спецификаций «контроллера» для интеграции на самом деле должно быть хорошо. Или, если вы действительно хотите «правильное» полное интеграционное тестирование: сделайте себе одолжение и используйте capybara / rspec вместо Cucumber ...

...