Comments 6
Допустим, мы написали простейшую функцию:
Вспоминая опыт портирования crtl...
strtoimax()/strtoumax(): по 10 тест-кейсов,
getline()/getdelim(): по 12,
и т.д. И это только unit-тесты.
Плюсанул статью, хотя бы за то что в ней отсутствует codeigniter в качестве серебряной пули.
Акцентирую внимание на одном моменте:
В начале статьи автор рассказывает о ручном тестировании через Postman, а потом приводит несколько примеров по созданию пирамиды тестов.
Постман умеет не только хранить запросы во всей их красе, но также умеет в команды, что резко снижает временную стоимость рефакторинга, как факт. Сколько потребуется времени на написание текстов из статьи, создание моковых наборов, особенно для покрытия всех краевых событий хорошо изложено в статье.
Овичнка точно стоила выделки? ;) При этом никоим боком не против автотестирования, но может примеры слишком переусложнены?
Согласен постманом тоже можно, все зависит от специфики вашего приложения и цикла разработки.
Если над проектом трудится 1-2 человека в режиме поддержки, то да, можно и с постманом проверять.
А если у вас команда из 10-20 инженеров, релизы выкатываются каждый день или просто сложная бизнес-логика, то без автоматизации никак не обойтись, иначе получим баги на проде или крайне высокий TMM (time-to-market).
Коллекции postman можно гонять автоматически через newman, в свою очередь все это флоу можно положить в ci. Что в таком случае блочит 20 инженеров с релизами каждый день?
Если на проекте трудится 20+ инженеров, значит разрабатываемого функционала достаточно много.
Это в свою говорит нам о том, что тест-кейсов тоже должно быть достаточно большое кол-во.
Ведь 20 человек работают параллельно и если каждый не покроет свой функционал тестами, то велика веротность того, что постоянно что-то будет ломаться.
Почему постман не подойдет:
1. Скорее всего все кейсы покрыть не получится, т. к. в постмане вы ничего не контролируете кроме ответа и запроса. Вы не сможете в постмане подменить данные в БД или замокать что-то (в статье об этом написано), а значит какая-то часть сценариев останется без тестового покрытия и может пострадать.
2. Если использовать только постман, то кол-во тестов станет достаточно большим. Постман тесты будут самыми медленными и нестабильными из предложенных в этой статье. Значит тесты в ci/cd будут занимать какое-то время и будут периодически флакать. При частых релизах это может стать проблемой.
Но в целом любой подход имеет свои плюсы и минусы. Я поделился мнением исходя из своего опыта. Опыт подсказывает мне, что серебрянной пули нет и для эффективной работы придется комбинировать разные подходы и инструменты, что и было описано в этой статье)
Это будут е2е тесты которые требуют инфраструктуру и все вытекающее от верхушки пирамиды. Протестить все граничные кейсы тоже будет трудно. Постман неплох как апи тесты, никто не спорит, но этого недостаточно
Как и зачем тестировать код на бэкенде: рекомендации для новичков