Home

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В этой серии коротких статей я хочу поделиться рядом примеров использования RestAssured.Net для создания тестов REST/GraphQL API.

• Начало работы и простые примеры
• Параметризация тестов (эта статья)
• Прямое и обратное преобразование
• Авторизация и повторное использование
• Тестирование GraphQL API

Все примеры из статьи можно найти на GitHub.

Параметризация тестов

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

В результате тестирование API и его внедрения до определенной степени покрытия зачастую требует многократного обращения к одной и той же конечной точке – с разными значениями ввода и ожидаемыми результатами.

Наивный подход к созданию таких тестов – это простое копирование и вставка одного теста в другой с заменой жестко закодированных значений согласно нуждам теста. В результате, однако, мы получим кучу дупликации и набор тестов, который сложно читать и поддерживать.

Гораздо лучше создать то, что называют параметризованным тестом – его еще зовут тестом, управляемым через данные. В этой статье я покажу вам, как это делается с RestAssured.Net.

Указываем параметры запроса

API принимают данные различными способами. В примерах из этой статьи мы сконцентрируемся на параметрах запроса и пути. В следующей статье мы подробнее разберем отправку данных в содержании запроса.

Задать параметры запроса и их значения в RestAssured.Net можно разными способами, но все они сводятся к присваиванию правильно отформатированных пар ключ-значение строке конечной точки. Это можно сделать при помощи конкатенации или интерполяции строк – как вам больше нравится.

Однако RestAssured.Net также располагает служебным методом QueryParam(), который немного упрощает добавление параметров запроса и их значений к конечной точке – вот пример:

[Test]
public void QueryParameterExample()
{
    Given()
    .QueryParam("text", "RestAssured.Net")
    .When()
    .Get("http://md5.jsontest.com")
    .Then()
    .Body("$.original", NHamcrest.Is.EqualTo("RestAssured.Net"))
    .Body("$.md5", NHamcrest.Is.EqualTo("3d0761128d4c535dd4ee69b54abde303"));
}

В этом тесте вызывается конечная точка http://md5.jsontest.com?text=RestAssured.Net.

Чтобы задать несколько параметров запроса, можно вызвать QueryParam() несколько раз, или передать в этот метод словарь с именами параметров и их значениями. Больше примеров – в руководстве пользователя RestAssured.Net.

Задаем параметры пути

Тот же принцип можно использовать и при задании параметров пути. Помимо интерполяции и конкатенации строк RestAssured.Net предлагает метод PathParam() для присвоения значения параметру пути.

[Test]
public void PathParameterExample()
{
    Given()
    .PathParam("countryCode", "us")
    .PathParam("zipCode", 90210)
    .When()
    .Get("http://api.zippopotam.us//")
    .Then()
    .Body("$.places[0].['place name']", NHamcrest.Is.EqualTo("Beverly Hills"));
}

Конечная точка в этом тесте - http://api.zippopotam.us/us/90210.

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

Затем RestAssured.Net будет искать плейсхолдер (идентифицируемый нотацией 'пара одиночных кавычек') с таким же именем в конечной точке и заменит его значением, заданным в методе PathParam().

Как можно видеть, добавлять можно и несколько параметров пути. Можно также воспользоваться PathParams() для привязки словаря параметров пути к единичному вызову метода. Больше примеров использования параметров пути – в руководстве пользователя RestAssured.Net.

Создание параметризованного теста

Теперь, добавив к тесту определения параметров, можно объединить их с возможностями средства запуска тестов и создать параметризованный тест.

В этом примере я пользуюсь NUnit, но большинство прочих известных мне средств запуска тестов (на C#, но и на других языках тоже) также поддерживают эту концепцию. В NUnit можно загружать тест-кейсы, используя аннотацию [TestCase]:

[TestCase("us", 90210, "Beverly Hills", TestName = "US zip code 90210 maps to Beverly Hills")]
[TestCase("ca", "Y1A", "Whitehorse", TestName = "CA zip code Y1A maps to Whitehorse")]
[TestCase("it", 50123, "Firenze", TestName = "IT zip code 50123 maps to Firenze")]
public void ParameterizedTestExample(string countryCode, object zipCode, string expectedPlace)
{
    Given()
    .PathParam("countryCode", countryCode)
    .PathParam("zipCode", zipCode)
    .When()
    .Get("http://api.zippopotam.us//")
    .Then()
    .Body("$.places[0].['place name']", NHamcrest.Is.EqualTo(expectedPlace));
}

Как видно, мы передаем значения, которые хотим использовать в тесте в качестве аргументов тест-метода, а затем заменяем значения, жестко закодированные в тест-методе, на свои аргументы. NUnit затем запустит метод трижды, по разу для каждого заданного нами [TestCase].

Альтернатива опции [TestCase], которая лучше масштабируется и позволяет пользоваться внешними источниками данных (или применять некую логику для расчета или вывода значений) – это использование атрибута [TestCaseSource]. Эта возможность задокументирована тут, а пример для RestSharp можно найти здесь.

Вот и все, что касается работы с параметрами и создания параметризованных тестов в RestAssured.Net. В следующей статье серии мы посмотрим на эффективное создание содержания запросов и обработку содержания ответов путем (обратного) преобразования.

Обсудить в форуме