Разбираемся в REST assured как новичок и не только11.07.2023 17:46

Начнём с азов

Почему бы нам просто не перестать тестировать вручную?  

• Ведь это экономит время. Это очевидно, потому что прогнать автотест займет считанные секунды, а то и доли секунд, а вручную — десятки секунд, а то и несколько минут.

• Автотест автоматически сгенерит нам документацию и отчётность. 

• Затем автотест позволит нам снизить влияние человеческого фактора. Где автотест, который правильно настроен, всегда пройдёт без ошибок, человек может ошибиться. 

• Высокий уровень точности, само собой, по сравнению с ручным тестированием.

Получается, автотесты — панацея, которую надо внедрять добровольно-принудительно? Это далеко не так.

В каких условиях нам НЕ пригодится автоматизация тестирования REST API

Случай №1 — на стадиях ранней разработки. 

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

Есть, конечно же, исключения. Бывают случаи, когда документация уже написана и, в принципе, API дальше меняться не будет. Тогда, конечно, можно начать писать автотесты параллельно с работой разработчика, который пишет эту API. Но, мне кажется, что такие ситуации всё-таки редки. 

Случай №2 — тесты, которые невозможно полностью автоматизировать.

Например, когда часть теста прогоняется вручную, а часть теста автоматизирована.

• Это нам не даёт никакой экономии времени, по большому счёту.

• Тесты становится сложнее поддерживать.

• И их достоверность под большим вопросом.

Для чего тогда нам нужны автотесты API?

№1. Они позволяют нам упростить локализацию бага. Когда мы тестируем через UI, нам надо сначала локализовать баг, понять, где он вообще находится. Когда мы тестируем через API, мы уже понимаем, где он находится. 

№2. Снижение стоимости обнаружения бага достигается благодаря тому, что мы тестируем на уровне API, а не на уровне UI. 

№3. И проверка на соответствие требованиям с точки зрения надёжности, безопасности и производительности.

Что же нам надо знать об API, которое мы тестируем?

№1. Для начала убедимся, что API смотрит на нужный стенд и базу данных. Какой смысл в неактуальных данных? Пускай даже тест прошёл, но он смотрит не туда. 

№2. Затем проверяем корректность входа состояния HTTP. 

№3. Проверяем полезную нагрузку ответа. Здесь нам надо проверить правильность тела JSON: имена, типы и значение полей ответа.

№4. Проверяем заголовки ответа. Они влияют как на безопасность, так и на производительность. 

№5. И проверяем базовую работоспособность. Если операция была завершена успешно, но заняла слишком много времени, то тест не пройден.

Последствия 

Какие ошибки мы можем допустить, если не выполним все эти проверки?  

• Неактуальные результаты тестирования. Когда мы смотрим, например, не на ту базу данных или не на тот стенд, мы получаем неактуальную информацию.

• Пропуск багов, в том числе критичных.

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

Какие виды тестовых сценариев мы используем?

• Основные позитивные тесты — это прохождение успешного сценария по умолчанию.

• Расширенное позитивное тестирование, где мы добавляем дополнительные параметры.

• И негативное тестирование. Здесь мы проверяем как валидные входные данные, так и недопустимые.

Также мне бы хотелось отметить, что всегда стоит уточнять. Коллеги с небольшим количеством опыта и те, кто только планирует начать работать в тестировании, обращаюсь к вам. Если что-то непонятно до конца — лучше лишний раз уточнить. Коллег с большим количеством опыта, прошу, пожалуйста, отвечайте на эти вопросы.

Коды состояния HTTP

Раз уж мы поговорили о том, что мы получаем в ответах, давайте вспомним и коды состояния HTTP. 

1хх — Informational. Сотые информационные коды нам говорят, что запрос получен и обработка продолжается.

2хх — Success. Двухсотые коды состояния говорят о том, что запрос был получен, успешно обработан и понят. 

3хх — Redirection. Трехсотые коды ответов говорят о том, что для выполнения запроса требуются ещё действия. 

4хх — Client Error: запросы имеют плохой синтаксис или не могут быть выполнены.

5хх — сервер не в состоянии выполнить недопустимый запрос.

Раз уж пойдёт речь о тестирование именно REST API, давайте же вспомним: что такое REST. 

Что такое REST?

REST или Representational State Transfer — это архитектурный стиль, который описывает взаимодействие компонентов распределённого приложения внутри сети. Другими словами, это такой набор ограничений, которые дают нам возможность в дальнейшем масштабировать приложение. 

RESTfull — это соответствие веб-службы требованиям REST.

REST — architecture

Вот мы уже плавно подошли к самой сути статьи, поэтому выделим…

Четыре основных REST-assured метода

• Given — позволяет узнать, что было передано в запросе.

• When — с каким методом и на какой эндпойнт отправляем запрос.

• Then — как проверяется пришедший ответ.

• Body — тело, в нашем случае, ответа.

REST-assured вообще представляет из себя инструмент для тестирования API, и он встраивается в тесты на Java. И здесь конкретный пример, точнее схема, как оно выглядит. 

given()...
  .when()
  .get(someEndpoint)
  .then()
  .statusCode(200)
  .body();

Также стоит использовать паттерн Builder. 

Паттерн Builder

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

Пример паттерна.

Account account = new AccountBuilder()
                .withId(1)
                .withName("test")
                .withBalance(10)
                .build();

Если обратить внимание, то заметим, что REST-assured соответствуют паттерну Builder. 

Перейдём к примеру

Что нам потребуется для подготовки?  

В данном случае, у нас будет тестироваться API, которая принимает параметры поиска офисов и выдаёт в результате список информации про каждый офис. 

Будем использовать следующий стек: ЯП Java, библиотека REST-assured и jUnit5, и паттерн Builder. 

Учитываем все особенности проекта 

К примеру, в нашем случае особенность заключается в том, что мы не знаем, что происходит под капотом, поскольку мы обращаемся в закрытый сервис. Нам приходится довольствоваться только ответом, который он нам возвращается. 

Можно было бы порт прописывать напрямую в URL.

BASE_URL = "http://alfaххх-intХ:ХХХХ/ххххххх-ххххх-ххх-хххх-api"

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

public class MarathonUtils {
    private static final String protocol = "http";

    public static String getServiceBaseUrl(String serviceMarathonPath) {

        Response response = RestAssured.given()
                .auth().basic(getPropertyOfName("mLogin"), getPropertyOfName("mPassword"))
                .baseUri(protocol + getPropertyOfName("mUri"))
                .basePath(serviceMarathonPath)
                .get("?embed=app.taskStats&embed=app.readiness")
                .then()
                .statusCode(200)
                .extract().response();
        //Возвращает первый найденный объект с информацией о работающем инстансе.
        Map state = response.getBody().path("app.tasks.find { it.state == 'TASK_RUNNING' }");

        if (state != null) {
            String host = state.get("host").toString();
            @SuppressWarnings("unchecked")
            ArrayList ports = (ArrayList) state.get("ports");
            String uri = response.getBody().path("app.env.SERVICE_NAME").toString();
            return String.format("%s://%s:%s/%s", protocol, host, ports.get(0), uri);
        }

        throw new NullPointerException("Отсутствуют работающие инстансы для " + serviceMarathonPath);
    }
}

Далее составляем JSON-schema по телу ответа API

Давайте посмотрим на неё. Это фрагмент схемы, который используется для тестирования данного проекта и данной API.

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "type": "array",
  "items": [
    {
      "type": "object",
      "properties": {
        "pid": {
          "type": "string"
        },
        "uuid": {
          "type": "string"
        },

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

Что проверяет схема?  

Она проверяет тип данных. В зависимости от типа данных может применить дополнительные правила. Например, для типа данных Integer можно проверить минимальное-максимальное число, для массива Array — максимальное количество элементов, обязательность элементов (required) и так далее. 

А вот пример схемы сложнее, подробнее и информативнее.

{ 
    "$schema": "http://json-schema.org/draft-03/schema#", 
    "id": "urn:product_name#", 
    "type": "string", 
    "pattern":     "^\\S.*\\S$", 
    "minLength": 3, 
    "maxLength": 50, 
}

Примечание: JSON-schema используется, потому что гораздо проще проверять по ней, чем каждый отдельный параметр. API отдаёт нам информацию в большом объёме, почему бы не использовать JSON-schema, в которой мы можем прописать абсолютно всё?

Напишем автотест на базовую проверку

@ExtendWith(ReportPortalExtension.class)
public class BaseTest {
    static RequestSpecification requestSpecification;


    @BeforeAll
    static void setUp() {
        requestSpecification = RestAssured.given()
                .baseUri(BASE_URL_POS)
                .accept(ContentType.JSON);
    }

    public static ValidatableResponse checkStatusCodeInResponse(String url, int code, String schema)
    {
        return RestAssured.given(requestSpecification)
                .get(url)
                .then()
                .statusCode(code)
                .body(matchesJsonSchemaInClasspath(schema))
                .time(lessThan(1500L));
    }

    public void baseNegativeCheck(String posUrl) {
        checkStatusCodeInResponse(posUrl, CLIENT_ERROR_CODE, POS_API_SCHEMA_ERROR_JSON);
    }

    public void basePositiveHasItemsCheck(String path, String item, String posUrl, String schema) {
        checkStatusCodeInResponse(posUrl, SUCCESS_CODE, schema)
                .body(path, hasItems(item));
    }

    public void hasSizeCheck(String url, String path, int size) {
        checkStatusCodeInResponse(url, SUCCESS_CODE, POS_API_SCHEMA_EMPTY_JSON)
                .body(path, hasSize(size));
    }

    public void equalToCheck(String url, String path, String schema, boolean operand) {
        checkStatusCodeInResponse(url, SUCCESS_CODE, schema)
                .body(path, equalTo(operand));
    }

    public void positiveHasEntryCheck(String url, String path, String key, String value) {
        checkStatusCodeInResponse(url, SUCCESS_CODE, POS_API_SCHEMA_JSON)
                .body(path, everyItem(hasItem(hasEntry(key, value))));
    }

    public void checkEveryItemHasSize(String url, int size, String path) {
        checkStatusCodeInResponse(url, SUCCESS_CODE, POS_API_SCHEMA_EMPTY_JSON)
                .body(path, everyItem(hasSize(size)));
    }

    public void checkEveryItemLessOrEqualValue(String url, String path, String value) {
        checkStatusCodeInResponse(url, SUCCESS_CODE, POS_API_SCHEMA_EMPTY_JSON)
                .body(path,everyItem(lessThanOrEqualTo(parseFloat(value))));
    }

    public void checkEveryArrayHasItem(String path, String item, String posUrl, String schema) {
        checkStatusCodeInResponse(posUrl, SUCCESS_CODE, schema)
                .body(path, array((containsString(item))));
    }
}

Здесь мы задаём requestSpecification, который представляет из себя преднастройку для запросов. Он будет применяться для всех тестов, которые будут наследоваться от данного класса. Мы в нём передаём URI, путь, методы, к примеру, accept — он у нас будет проверять тип данных. Здесь же мы видим применение уже знакомых нам given, then и body. 

В базовую проверку добавлена проверка на время отклика (1500 мс), что не заменяет в полной мере нагрузочное тестирование, но даёт возможность обнаружить проблему с производительностью на более раннем этапе тестирования. 

Тест.

  @DisplayName("Проверка соответствия первого офиса по городу \"Санкт-Петербург\"")
    @Positive
    @Test
    public void testSPB() {
        basePositiveHasItemsCheck("pid", "0819", getCityAndMetroAndLimitUrl("Санкт-Петербург", METRO_VALUE, LIMIT_1), POS_API_SCHEMA_JSON);
    }

А для проверки ответа описаны объекты:

@Data
@NoArgsConstructor
@AllArgsConstructor
public class FullPosOfficesPojo {
    private String pid;
    private String uuid;
    private String mnemonic;
    private String title;
    private String address;
    private List metro;
    private Boolean embossingEnabled;
    private List prodType;
    private List kinds;
    private Boolean close;
    private String clientAvailability;
    private String addressOfficial;
    private List schedule;
    private List