Может и не нужно тестировать API?

Всем привет ✍️

Сегодня мы попробуем разобраться зачем же нам тестировать API и когда стоит начинать это благое дело.

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

Тестирование API в первую очередь проверка работы бэкенд разработчика.

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

Тестирование API важно, поскольку оно помогает убедиться, что бэкенд приложения работает правильно и может обрабатывать различные типы запросов и нагрузок. Оно также может помочь выявить любые проблемы или ошибки в коде бэкенда, которые могут повлиять на производительность или функциональность приложения в целом.

Чуть позже мы разберем данную тему на практике и тогда все станет намного подробнее)

Зачем и когда мы начинаем тестировать API

С тестированием API работает та же логика как и с остальными видами тестирования.

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

Что же нам нужно проверять при тестировании API?

Перед тем как начать тестировать API нам необходимо получить API документацию.

Зачем же нам нужна API документация?

На этот вопрос есть очень логичный ответ:

Бэкенд код пишет Бэкенд разработчик и только он знает как работает его код.

Насколько мы знаем бэкенд разработчик пишет функции которые впоследствии будут принимать наши запросы и в которые фронтенд разработчик так же будет отправлять свои запросы.

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

Какие поля нам нужны в API документации?

1. Метод запроса (Обязательный параметр), Например: GET, POST, PUT, DELETE и так далее
2. Конечная точка запроса (Обязательный параметр) - адрес функции бэкенд разработчика которая принимает запрос (так же может называться endpoint, ручка и так далее), Например: доменное_имя_вашего_сайта/registration
3. Способ авторизации (Необходим если для запроса необходима авторизация), Существуют различные способы. Нужно уточнять у вашего бэкенд разработчика
4. Тело запроса (Необходимо если отправляем данные), Например: {"name":"Your_name","email":"youremail@gmail.com"}
5. Код ответа (Обязательный параметр), Например: 200, 201
6. Тело ответа (Обязательный параметр), Например {

"email": "youremail@gmail.com",

"id": 1,

"name": "Your_name"

}

Какие основные проверки мы должны сделать?

Давайте немного попрактикуемся.

В API документации мы получили вот такие данные:

Данный запрос используется для создания нового пользователя в нашем приложении

Метод запроса: POST

Конечная точка запроса: /users

Способ авторизации: авторизация не требуется

Тело запроса: {"name":"Your_name","email":"youremail@gmail.com"}

параметр name отвечает за имя пользователя (Обязательный)

параметр email отвечает за email пользователя (Обязательный, Уникальный)

Код ответа: 201

Тело ответа: {

"email": "youremail@gmail.com",

"id": 1,

"name": "Your_name"

}

параметр email отвечает за email пользователя (Обязательный, Уникальный)

параметр name отвечает за имя пользователя (Обязательный)

параметр id отвечает за идентификацию пользователя (Обязательный, Уникальный)

В дальнейшем параметр используется для поиска пользователя по его id.

Какие же проверки мы можем использовать для нашего запроса?

Как обычно начинаем с позитивной проверки.

1. Отправляем запрос с валидным методом, конечной точкой запроса, телом запроса (копируем из документации) Ожидаемый результат: получаем 201 код ответа и тело ответа содержащее поля email, id, name с корректными значениями

Далее можно пойти и по негативным сценариям)

1. Отправляем запрос с валидным методом, конечно точкой запроса, без тела запроса. Ожидаемый результат: получаем сообщение об ошибке
2. Отправляем запрос с валидным методом, конечной точкой запроса, в теле запроса удаляем параметр name ({"email":"youremail@gmail.com"}). Ожидаемый результат: получаем сообщение об ошибке "поле "name" обязательный параметр"
3. Отправляем запрос с валидным методом, конечной точкой запроса, в теле запроса удаляем параметр email ({"name":"Your_name"). Ожидаемый результат: получаем сообщение об ошибке "поле "email" обязательный параметр"
4. Выполняем 2 раза валидный сценарий. Ожидаемый результат: получаем сообщение об ошибке "Данный email уже занят"

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

1. Отправляем запрос с валидным методом, конечной точкой запроса, в теле запроса в значении параметра email удаляем знак @ ({"name":"Your_name","email":"youremailgmail.com"}). Ожидаемый результат: получаем сообщение об ошибке: "Email должен содержать знак @"
2. Отправляем запрос с валидным методом, конечной точкой запроса, в теле запроса оставляем пустым значение параметра email ({"name":"Your_name","email":""}). Ожидаемый результат: получаем сообщение об ошибке
3. Отправляем запрос с валидным методом, конечной точкой запроса, в теле запроса оставляем пустым значение параметра name ({"name":"","email":"youremail@gmail.com"}). Ожидаемый результат: получаем сообщение об ошибке

Продолжать данный чек лист можно еще очень долго.

Как видите чек - лист проверок API ничем не отличается от обычных проверок при ручном тестировании фронтенда.

Так же мы должны не забывать о нефункциональных требованиях.

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

На этом пока все

Если вам хочется поддержать выпуск статей можете отправить донат в boosty - https://boosty.to/victoryaroshuk.qa

По поводу индивидуальных занятий пишите - https://t.me/sdetqackick