Прекратите спамить UI-тестами!

Если попытаться определить значимость различных типов автотестов, изучая количество обучающих материалов и статей в Сети, то можно подумать, что 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. Ваш набор автотестов станет быстрее, надежнее, и проще в поддержке.

Оригинал статьи: http://thethinkingtester.blogspot.com/2019/07/stop-writing-so-many-ui-tests.html

Перевод статьи: https://software-testing.ru/component/content/article/3299-stop-writing-so-many-ui-tests