Я хочу проверить маршрут для добавления события. Но проблема в том, что этот метод отправляет много аргументов в POST о: 50. Я пытался:
Scenario Outline: Check Api Simple Test
Given I use http method "POST"And I have param "sEventType" with value "<sEventType>"And I have param "aFilters[]" with value "<aFilters[]>"And I have param "nCompany" with value "<nCompany>"..................................................
And I call url "<path>"And I should to have "code" with value "<code>"And I should to have "error" with value "<error>"Examples :
|path ........
|..............
Для многих аргументов эти примеры сделают эту функцию неразборчивой. Какова лучшая практика, чтобы проверить этот маршрут со многими аргументами. Пожалуйста, помогите мне и спасибо заранее!
Функциональный тест с длинным списком шагов является анти-паттерном. Делайте больше в каждом шаге, написанном в коде, а затем повторно используйте эти шаги по мере необходимости. У меня есть некоторые контексты функций, которые просто включают несколько черт, которые могут работать вместе, чтобы делать то, что мне нужно.
Иногда код может быть списком того, что было бы веб-шагами (у меня есть функция регистрации, которая является visit (‘url’) fillFields (), pressButton ()), в других случаях они читают или записывают в базу данных ,
Scenario Outline: Check Api Simple Test
Given I prepare an API with appropriate parameters
When I call url "<path>"Then I should to have "code" with value "<code>"And I should to have "error" with value "<error>"
Что касается приемочного тестирования, то, что вы пытаетесь назвать, называется интеграционным тестом.
Если вы хотите, чтобы эти сообщения были опубликованы, просто посетите (URL), при необходимости заполните форму и затем отправьте. Именно так ваши пользователи должны будут заполнить форму. Если это слишком много для вас, может быть, это слишком много для вас, пользователей.
When I fill in "form_element_name" with "value"And I press "submit"Then I should see "resultz"
Однако, если это действительно то, что вам нужно, создайте определение шага «опубликуйте много переменных» и внедрите детали в свой контекстный файл.
Я бы использовал интеграционный тест для тестирования контроллера, когда он является только конечной точкой API.
В качестве альтернативы, вы можете использовать TableNodes (я знаю, что я немного опоздал на вечеринку), но в действительности, если вы используете что-то вроде этого фрагмента:
/**
* @Then /^I have the following param(?:|eter)s with values:$/
*/
public
function iHaveTheFollowingParamsWithValues(TableNode $table)
{
foreach ($table->getRowsHash() as $param => $value) {
$this->iHaveParamWithValue($param, $value);
}
}
А также:
/**
* @Then /^I should have the following codes with values:$/
*/
public
function iShouldHaveTheFollowingCodesWithValues(TableNode $table)
{
foreach ($table->getRowsHash() as $code => $value) {
$this->iShouldHaveCodeWithValue($code, $value);
}
}
Он вызовет указанные вами функции и позволит вам записать данные в таблицу, как в таблице примеров в наброске сценария.
Такие как:
Scenario Outline: Check Api Simple Test
Given I use http method "POST"
And I have the following params with values:
|sEventType|<sEventType>|
|aFilters[]|<aFilters[]>|
|nCompany |<nCompany> |
..................................................
And I call url "<path>"
And I should have the following codes with values:
|code |<code> |
|error|<error>|
Examples :
|path ........
|..............
Это должно способствовать удобочитаемости и ускорить написание теста и выполнение теста на небольшую величину.