Большое спасибо за статью! Информация крайне удобно поделена на блоки и собрано очень много всего. Для совсем новичков, возможно будет "передоз" знаний. Но, если ты уже что-то умеешь, отлично подойдет освежить теорию и (в моем случае) узнать немного новых деталей о которых "вроде слышал", но как-то никогда руки не добирались разобраться подробней
Касаемо мух и котлет. Согласна, получилось как-будто две темы в одной статье. Напишу отдельную статью по запросам, где раскрою все чуть подробнее и детальнее. Конечно, эта тема не новая, но я скорее для себя: неплохо лишний раз все структурировать и прописать текстом)
Говоря про постман – да, он сильно изменился со временем. Но мне кажется, что он не потерял свою легкость, если не пользоваться ничем лишним. Чувствуется их стремление создать экосистему вокруг работы с API, хотя не всегда ясно зачем. На моей практике он показал себя достойно как в работе небольшого стартапа, так и в разработке большого коммерческого проекта
Для себя я решила так:
Выбирая постман в качестве экосистемного решения мы получаем неплохую функциональность из коробки и с маленькой болью. Отличное решение, чтобы запустить проект «завтра»
А вот с развитием проекта, постмана начнет не хватать. Например, с ростом команды станет все сложнее поддерживать коммуникацию: договариваться о том, как что будет работать. Часто в таких случаях на сцену выходит openApi. Пишем контракт, и параллельно приступаем к разработке
Так, Postman со временем все меньше и меньше заменяет собой инфраструктуру тестирования и приходит к своим истокам: CURL с UI
Говоря про ваши аргументы:
1. Дробление тестов. Абсолютно согласна, это не очень хорошо. Но здесь важно учесть одно – есть ли в проекте еще какие-либо тесты, кроме тех, которые пишутся в Postman? Мне как-то не везло, и обычно, в командах разработки все не очень хорошо с написанием тестов :c (Как-же хочется в мир с TDD)
2. Да, идея интересная. Все чаще вижу, как QA специалисты занимаются написанием модульных и даже иногда юнит тестов. Часто все сводится к стоимости часа. Бекендеры дороже, вот и выходит так, что с учетом текущего бюджета дешевле заслать QA специалистов пописать тесты. Но и тут опять же бьемся о внешние условия: а хватает ли ресурса бекендеров, все качественно описывать и писать хоть какие-то тесты? Обычно, нет. И приходится ходить и спрашивать, спрашивать, спрашивать...
3. Да, согласна полностью. Меньше инструментов – легче жизнь. Я не вижу Postman как экосистему, постоянным решением. Скорее, одним из начальных этапов в жизни продукта. Как и сам проект, его инфрастурктура развивается, и более подходящие экосистемные решения вымещают постман, возвращая его в состояние удобного инструмента для мануального тестирования
Тут важно разделить задачи, которые решают эти инструменты.
Postman сейчас, скорее про экосистему: документация, сами запросы, окружния, тесты. Все в одной красиво запакованной коробочке.
А jest - библиотека. Решает саму задачу «проверки», но не более. Есть еще отличные библиотеки: Frisby (построен на основе Jest) или Supertest, которые упрощают тестирование API с помощью кода
Соответственно и выбрать стоит то, что больше подходит для нужд проекта сейчас. Если у вас уже есть развитая инфраструктура тестирования, где имеются разные инструменты (а-ля TestIT, Allure и вот этот весь компот), а еще есть и чудесные DevOps инженеры, то, кажется, Postman - не лучший выбор для написания автотестов, но все еще отличный инструмент для мануального тестирования
Важно скорее не то, что умеет инструмент, а то, для чего и как мы собираемся им пользоваться. Выбирая постман в качестве экосистемного решения мы получаем неплохую функциональность из коробки и с маленькой болью. Для небольшой команды с небольшим бюджетом - очень неплохо. С ростом проекта, стоит двигаться в сторону кастомной инфраструктуры тестирования, создавая решение четко под запросы проекта
Большое спасибо за статью! Информация крайне удобно поделена на блоки и собрано очень много всего. Для совсем новичков, возможно будет "передоз" знаний. Но, если ты уже что-то умеешь, отлично подойдет освежить теорию и (в моем случае) узнать немного новых деталей о которых "вроде слышал", но как-то никогда руки не добирались разобраться подробней
Спасибо автору и его команде за труды!)
Касаемо мух и котлет. Согласна, получилось как-будто две темы в одной статье. Напишу отдельную статью по запросам, где раскрою все чуть подробнее и детальнее. Конечно, эта тема не новая, но я скорее для себя: неплохо лишний раз все структурировать и прописать текстом)
Говоря про постман – да, он сильно изменился со временем. Но мне кажется, что он не потерял свою легкость, если не пользоваться ничем лишним. Чувствуется их стремление создать экосистему вокруг работы с API, хотя не всегда ясно зачем. На моей практике он показал себя достойно как в работе небольшого стартапа, так и в разработке большого коммерческого проекта
Для себя я решила так:
Выбирая постман в качестве экосистемного решения мы получаем неплохую функциональность из коробки и с маленькой болью. Отличное решение, чтобы запустить проект «завтра»
А вот с развитием проекта, постмана начнет не хватать. Например, с ростом команды станет все сложнее поддерживать коммуникацию: договариваться о том, как что будет работать. Часто в таких случаях на сцену выходит openApi. Пишем контракт, и параллельно приступаем к разработке
Так, Postman со временем все меньше и меньше заменяет собой инфраструктуру тестирования и приходит к своим истокам: CURL с UI
Говоря про ваши аргументы:
1. Дробление тестов. Абсолютно согласна, это не очень хорошо. Но здесь важно учесть одно – есть ли в проекте еще какие-либо тесты, кроме тех, которые пишутся в Postman? Мне как-то не везло, и обычно, в командах разработки все не очень хорошо с написанием тестов :c (Как-же хочется в мир с TDD)
2. Да, идея интересная. Все чаще вижу, как QA специалисты занимаются написанием модульных и даже иногда юнит тестов. Часто все сводится к стоимости часа. Бекендеры дороже, вот и выходит так, что с учетом текущего бюджета дешевле заслать QA специалистов пописать тесты. Но и тут опять же бьемся о внешние условия: а хватает ли ресурса бекендеров, все качественно описывать и писать хоть какие-то тесты? Обычно, нет. И приходится ходить и спрашивать, спрашивать, спрашивать...
3. Да, согласна полностью. Меньше инструментов – легче жизнь. Я не вижу Postman как экосистему, постоянным решением. Скорее, одним из начальных этапов в жизни продукта. Как и сам проект, его инфрастурктура развивается, и более подходящие экосистемные решения вымещают постман, возвращая его в состояние удобного инструмента для мануального тестирования
Тут важно разделить задачи, которые решают эти инструменты.
Postman сейчас, скорее про экосистему: документация, сами запросы, окружния, тесты. Все в одной красиво запакованной коробочке.
А jest - библиотека. Решает саму задачу «проверки», но не более. Есть еще отличные библиотеки: Frisby (построен на основе Jest) или Supertest, которые упрощают тестирование API с помощью кода
Соответственно и выбрать стоит то, что больше подходит для нужд проекта сейчас. Если у вас уже есть развитая инфраструктура тестирования, где имеются разные инструменты (а-ля TestIT, Allure и вот этот весь компот), а еще есть и чудесные DevOps инженеры, то, кажется, Postman - не лучший выбор для написания автотестов, но все еще отличный инструмент для мануального тестирования
Важно скорее не то, что умеет инструмент, а то, для чего и как мы собираемся им пользоваться. Выбирая постман в качестве экосистемного решения мы получаем неплохую функциональность из коробки и с маленькой болью. Для небольшой команды с небольшим бюджетом - очень неплохо. С ростом проекта, стоит двигаться в сторону кастомной инфраструктуры тестирования, создавая решение четко под запросы проекта