опыта в написании таких тестов нет. Из того, что нашел, это в основном использование Java + rest-assured. Но хотелось бы узнать ещё какие стеки, инструменты, библиотеки используются, их плюсы и минусы. Что правильно погуглить, чтобы погрузиться в тему? Или может у кого-то уже есть под рукой хорошие статьи на этот счёт, был бы очень признателен, если кинете ссылочкой
Материалы от сообщества COMAQA: https://www.youtube.com/watch?v=gc4jlXfjNow https://www.youtube.com/watch?v=VTVx5Rx6rsY https://www.youtube.com/watch?v=Tq2thhEiQJE Обзорный "путь" http://katrinatester.blogspot.com/2015/09/api-web-services-microservices-testing.html Репозиторий по инструментам вообще. Инструменты разбиты по языкам и категориям: https://github.com/atinfo/awesome-test-automation/blob/master/java-test-automation.md#api-test-automation Эта ссылка на Java & API, но в документах репозитория есть много больше.
Python + Requests + Pytest. Просто, быстро, ничего лишнего. В качестве аналога ресташшурд я бы советовал использовать Unirest или что-то аналогичное. Рест ашшуред совсем монструозный.
При необходимости сюда можно добавить schematics
Спасибо. А тогда такой вопрос: если разработка на java, будет проблемно использовать тот стек, что ты посоветовал (Python + Requests + Pytest)? Я так понимаю, тогда лучше и тесты на джаве писать
Как связан язык разработки и язык для e2e тестов? И в чем по вашему может возникнуть проблема?
А тут речь разве про e2e?
Ок, апи тесты, разницы особой нет
Смотри, использовать тот же стек имеет смысл по четырем основным причинам. 1. Код тестов будет частью кода приложения. Это актуально для внутри-компонентных тестов, юнитов и прочего. Для API тестов, как и E2E, не особенно актуально. 2. Разработчики будут взаимодействовать с кодом тестов - актуализировать и дополнять тесты, дебажить, ревьюить или ещё что-то. Это сильно зависит от команды и обычно разработчикам это не сильно-то нужно. Но это надо обсуждать с командой. 3. Ты не шаришь и рассчитываешь на помощь разработчиков. Это действительно хорошо и удобно, когда можно придти за советом к коллегам и они тебе посоветуют подход\либу\етк. Плюс, банальное "поревьюйте мой код". Тоже ситуативная штука, потому что далеко не всегда нужно и стоит того. 4. Не плодить энтропию. С точки зрения архитектуры, инфраструктуры, управления зависимостями и прочим. Количество необходимой работы может сильно отличаться и, например, одно дело добавить ещё один докер контейнер в docker-compose, другое дело - прокидывать python и все зависимости на все целевые машины (билд агенты, локальные машины, прочее). Как видите, из 4 пунктов 1 неактуален, а остальные три - сильно ситуативные. Поэтому правильного ответа "надо ли мне использовать тот же стей, что и команда" - нет. В некоторых случаях это проще, быстрее и правильнее, в некоторых случаях это больно и бессмысленно.
IMHO, уж лучше marshmallow или cerberus.
Понял, спасибо за развёрнутый ответ
Их не трогал, надо будет посмотреть сравнить, спасибо :)
Ну, маршмеллоу - довольно стандартный инструмент для сериализации + валидации. Cerberus - ещё более простая и легковесная история. Обе, на мой взгляд, сильно менее объемные и более pythonic-way, нежели схематика. Но это всё, конечно, оценочные суждения.
Обсуждают сегодня