Если на проекте трудится 20+ инженеров, значит разрабатываемого функционала достаточно много.
Это в свою говорит нам о том, что тест-кейсов тоже должно быть достаточно большое кол-во.
Ведь 20 человек работают параллельно и если каждый не покроет свой функционал тестами, то велика веротность того, что постоянно что-то будет ломаться.
Почему постман не подойдет: 1. Скорее всего все кейсы покрыть не получится, т. к. в постмане вы ничего не контролируете кроме ответа и запроса. Вы не сможете в постмане подменить данные в БД или замокать что-то (в статье об этом написано), а значит какая-то часть сценариев останется без тестового покрытия и может пострадать. 2. Если использовать только постман, то кол-во тестов станет достаточно большим. Постман тесты будут самыми медленными и нестабильными из предложенных в этой статье. Значит тесты в ci/cd будут занимать какое-то время и будут периодически флакать. При частых релизах это может стать проблемой.
Но в целом любой подход имеет свои плюсы и минусы. Я поделился мнением исходя из своего опыта. Опыт подсказывает мне, что серебрянной пули нет и для эффективной работы придется комбинировать разные подходы и инструменты, что и было описано в этой статье)
Согласен постманом тоже можно, все зависит от специфики вашего приложения и цикла разработки.
Если над проектом трудится 1-2 человека в режиме поддержки, то да, можно и с постманом проверять.
А если у вас команда из 10-20 инженеров, релизы выкатываются каждый день или просто сложная бизнес-логика, то без автоматизации никак не обойтись, иначе получим баги на проде или крайне высокий TMM (time-to-market).
Если на проекте трудится 20+ инженеров, значит разрабатываемого функционала достаточно много.
Это в свою говорит нам о том, что тест-кейсов тоже должно быть достаточно большое кол-во.
Ведь 20 человек работают параллельно и если каждый не покроет свой функционал тестами, то велика веротность того, что постоянно что-то будет ломаться.
Почему постман не подойдет:
1. Скорее всего все кейсы покрыть не получится, т. к. в постмане вы ничего не контролируете кроме ответа и запроса. Вы не сможете в постмане подменить данные в БД или замокать что-то (в статье об этом написано), а значит какая-то часть сценариев останется без тестового покрытия и может пострадать.
2. Если использовать только постман, то кол-во тестов станет достаточно большим. Постман тесты будут самыми медленными и нестабильными из предложенных в этой статье. Значит тесты в ci/cd будут занимать какое-то время и будут периодически флакать. При частых релизах это может стать проблемой.
Но в целом любой подход имеет свои плюсы и минусы. Я поделился мнением исходя из своего опыта. Опыт подсказывает мне, что серебрянной пули нет и для эффективной работы придется комбинировать разные подходы и инструменты, что и было описано в этой статье)
Согласен постманом тоже можно, все зависит от специфики вашего приложения и цикла разработки.
Если над проектом трудится 1-2 человека в режиме поддержки, то да, можно и с постманом проверять.
А если у вас команда из 10-20 инженеров, релизы выкатываются каждый день или просто сложная бизнес-логика, то без автоматизации никак не обойтись, иначе получим баги на проде или крайне высокий TMM (time-to-market).