Comments 13
Я всегда считал, что postman, это curl с ui. А для автотестов лучше писать код. К тому же здесь код по сути и пишется. Быть может лучше взять тот же jest?
Ну вот у нас тестировщики не пишут кода... но с постманом обращаются довольно ловко.
Тут важно разделить задачи, которые решают эти инструменты.
Postman сейчас, скорее про экосистему: документация, сами запросы, окружния, тесты. Все в одной красиво запакованной коробочке.
А jest - библиотека. Решает саму задачу «проверки», но не более. Есть еще отличные библиотеки: Frisby (построен на основе Jest) или Supertest, которые упрощают тестирование API с помощью кода
Соответственно и выбрать стоит то, что больше подходит для нужд проекта сейчас. Если у вас уже есть развитая инфраструктура тестирования, где имеются разные инструменты (а-ля TestIT, Allure и вот этот весь компот), а еще есть и чудесные DevOps инженеры, то, кажется, Postman - не лучший выбор для написания автотестов, но все еще отличный инструмент для мануального тестирования
Важно скорее не то, что умеет инструмент, а то, для чего и как мы собираемся им пользоваться. Выбирая постман в качестве экосистемного решения мы получаем неплохую функциональность из коробки и с маленькой болью. Для небольшой команды с небольшим бюджетом - очень неплохо. С ростом проекта, стоит двигаться в сторону кастомной инфраструктуры тестирования, создавая решение четко под запросы проекта
спасибо за статью!
касательно статьи непосредственно - лучше-бы мухи отдельно, котлеты отдельно - описание методов запросов и кодов http-ответов (ну этого-то и так предостаточно прям везде!) как-то отделить от использования инструмента было-бы замечательно.
имхо, конечно, но когда-то постман был удобным и небольшим - прикладной комфортный в использовании инструмент для того, чтобы набросать апи и поделиться с коллегами. сейчас это какой-то перегруженный комбайн, по которому уже нужны туториалы, чтобы проникнуться всеми фичами.
постмановский подход сейчас хорош только для команд с большими комплексными апи их сервисов, или когда предполагаются разные сценарии использования, разные окружения и нагрузки.
в остальных случаях, как по мне, он избыточен:
- тесты можно писать на том же стеке, на котором написан основной код. это зачастую много быстрее.
- дробление тестов - относящиеся к апи - в одной парадигме, остальные тесты - в другой.. а есть ещё, наверняка, куча других инструментов, используемых в команде. и вот разрастание этого зоопарка может стать избыточным, требовать всё больших и больших трудозатрат, в то время когда время на непосредственно разработку уменьшается.
- понятно, что идея делегировать тестировщикам апи-тесты звучит неплохо - но непосредственно разработчику перед этим всё-равно нужно описать методы перед передачей в тестирование, всё-равно нужно набрасывать какие-то тесты при отладке. т.е. нужно посмотреть, насколько выгодно по человекочасам.
- где больше людей, инструментов, технологий - всегда больше ошибок. ну вот такие вот мы, люди, разработчики - пишем одни ошибки исправляя другие. большее количество ошибок увеличивает время до выкатки - если в одном случае разработчик тратит большее количество времени на начальном этапе - набросав тесты для проверки корректности исполнения запросов, нагрузочные и передав это в тестирование - уже полдела сделано. а так - итерация за итерацией с футболом тасками.
собственно, хотелось-бы услышать мнение - где мои аргументы не катят, и в каких кейсах постмановский подход реально вас выручал?
Касаемо мух и котлет. Согласна, получилось как-будто две темы в одной статье. Напишу отдельную статью по запросам, где раскрою все чуть подробнее и детальнее. Конечно, эта тема не новая, но я скорее для себя: неплохо лишний раз все структурировать и прописать текстом)
Говоря про постман – да, он сильно изменился со временем. Но мне кажется, что он не потерял свою легкость, если не пользоваться ничем лишним. Чувствуется их стремление создать экосистему вокруг работы с API, хотя не всегда ясно зачем. На моей практике он показал себя достойно как в работе небольшого стартапа, так и в разработке большого коммерческого проекта
Для себя я решила так:
Выбирая постман в качестве экосистемного решения мы получаем неплохую функциональность из коробки и с маленькой болью. Отличное решение, чтобы запустить проект «завтра»
А вот с развитием проекта, постмана начнет не хватать. Например, с ростом команды станет все сложнее поддерживать коммуникацию: договариваться о том, как что будет работать. Часто в таких случаях на сцену выходит openApi. Пишем контракт, и параллельно приступаем к разработке
Так, Postman со временем все меньше и меньше заменяет собой инфраструктуру тестирования и приходит к своим истокам: CURL с UI
Говоря про ваши аргументы:
1. Дробление тестов. Абсолютно согласна, это не очень хорошо. Но здесь важно учесть одно – есть ли в проекте еще какие-либо тесты, кроме тех, которые пишутся в Postman? Мне как-то не везло, и обычно, в командах разработки все не очень хорошо с написанием тестов :c (Как-же хочется в мир с TDD)
2. Да, идея интересная. Все чаще вижу, как QA специалисты занимаются написанием модульных и даже иногда юнит тестов. Часто все сводится к стоимости часа. Бекендеры дороже, вот и выходит так, что с учетом текущего бюджета дешевле заслать QA специалистов пописать тесты. Но и тут опять же бьемся о внешние условия: а хватает ли ресурса бекендеров, все качественно описывать и писать хоть какие-то тесты? Обычно, нет. И приходится ходить и спрашивать, спрашивать, спрашивать...
3. Да, согласна полностью. Меньше инструментов – легче жизнь. Я не вижу Postman как экосистему, постоянным решением. Скорее, одним из начальных этапов в жизни продукта. Как и сам проект, его инфрастурктура развивается, и более подходящие экосистемные решения вымещают постман, возвращая его в состояние удобного инструмента для мануального тестирования
А если все GET,HEAD,OPTIONS,DELETE,PUT,PATCH завернуть в POST с json body, и обрабатывать все в нём, чем это плохо по сравнению с вызовами канонических атавизмов?
тем что это будет уже не rest api а чтото другое. а зачем вам заворачивать все в пост? . В рест апи удобно что есть один ресуры users к которому можно делать get post patch put delete запросы. адрес один а действие отличается в зависимости от типа запроса
Для чего вводились методы запросов можно почитать в соотв. RFC, например https://www.rfc-editor.org/rfc/rfc5789
Видимо эти rfc еще до json-ов придумали.
До моды на JSON пользовались XML.
А если посерьезнее, то пихание всего в JSON - это отход от "расово верной" разделенной архитектуры по замыслу модели OSI. Несмотря на то, что HTTP проник во многие ниши, одновременно же им дело не кончается. Наоборот, посмотрел на libp2p - там пытаются пропихнуть HTTP и браузерные костыли во все остальные места, для совместимости. Так что не считаю обертывание всего и вся в JSON+POST/GET злом, но знать логику суждений прежних надо бы, чтобы уметь взвесить свое нестандартное решение.
Как по мне, Postman довольно тяжеловесен. Неплохая альтернатива - Insomnia. Тоже на электроне, но работает как-то поотзывчивее, что ли.
хорошая статья, новичкам зайдет. Все грамотно расписано, спасибо.
Postman: Основы тестирования API и первые шаги с инструментом