Home

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Если попытаться определить значимость различных типов автотестов, изучая количество обучающих материалов и статей в Сети, то можно подумать, что UI-тесты наиболее важны. Однако это не так – очень многое можно протестировать другим способом, особенно через API. API-тесты быстрее и куда устойчивее UI-тестов, а еще их проще писать! Ниже – четыре типа тестов, которые больше подходят для тестирования через API.

Тесты авторизации: при помощи API-тестов можно легко прогнать множество комбинаций логина и пароля. Ответ на POST-запрос к конечной точке авторизации быстр, как ветер, в отличие от UI-теста, которому придется ждать заполнения полей логина и пароля, а затем дожидаться, когда ответ дойдет до браузера. Чтобы это доказать, я создала коллекцию тестов в Postman с 16 тестами авторизации, содержащими различные комбинации логина и пароля. Шестнадцать тестов прошли менее чем за три секунды! Представьте, сколько бы заняли аналогичные UI-тесты.

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

CRUD-тесты: тестируя функциональность CRUD, вы проверяете, как ваше приложение взаимодействует со своим хранилищем данных. Это лучше делать на уровне API. При помощи инструментов вроде Postman очень легко создать GET, POST, PUT и DELETE-тесты. Вы можете убедиться в правильности кодов ответов и тела ответов (если оно есть), а также прогнать GET-запросы, чтобы удостовериться, что POST, PUT и DELETE правильно сохранились в базе данных.

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

Негативные тесты: API-тестирование отлично подходит для негативных тестов, потому что позволяет не только быстро пробежаться по негативным сценариям, но и прогнать тесты, невозможные на уровне UI. К примеру, у вашей формы есть обязательное поле. В интерфейсе нельзя отправить форму, не заполняя это поле, потому что интерфейс просто не даст этого сделать. Однако на уровне API можно провести POST-запрос без нужного поля и проверить, что в результате получен ответ уровня 400. API-тесты также отлично подходят для тестирования безопасности приложения, потому что злоумышленники, скорее всего, будут атаковать именно на этом уровне.

Вот примеры негативных тестов, которые можно провести на уровне API:

• Отправка на некорректный URL
• Запрос без необходимой аутентификации
• Тестирование на IDOR
• Отправка с некорректными заголовками
• Отправка запроса без обязательного поля
• Попытка запроса с типом поля, нарушающим ограничения по типу или длине.
• Проверка, что в результате неверного запроса возвращается ошибка уровня 400.

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

Тестирование сложной бизнес-логики: если какая-то область вашего приложения требует сложной настройки данных и заковыристой бизнес-логики, куда легче тестировать через API, чем через UI. Возьмем, к примеру, мою гипотетическую фичу - Superball Sorter, сортировщик разноцветных мячиков разного раздела между четырьмя детьми. Установка правил через интерфейс при помощи автоматизированного теста будет очень сложной – если предположить, что у каждого ребенка есть выпадающее меню для размера и цвета, вам придется много раз заниматься выбором элементов. Однако если у сортировщика есть API, который позволяет задавать правила через единый POST-запрос, то на подготовку теста уйдет несколько миллисекунд.

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

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

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