тоже непонятно
я не работал с axios - но гугл дал в первой ссылке в выдаче решение из мануала

минутка юмора: иногда google translate переводит весело

npm я - спасаю кукловода @ далее

Пхпха

Это работает только если проект новый, а так трет историю. Надо или в самом начале проекта так делать или играть с флагами.

Ну или на стадии кодеревью по руками бить

не люблю я бить

npm я - спасаю кукловода @ далее

зачет) предлагаю окресить установку puppeteer'a "спасением кукловода") и популяризировать )

Всем привет. Есть, кто делает тестирование скриншотами и у кого это стоит на quality gate на дев пиары? Интересует какие у вас процессы (кто, как и когда обновляет скриншоты, где они лежат и т.д.)

У нас на проде висят тесты на скриншотах. На дев пока не стали. Скрины, естественно, должны быть в репо.

Ты имеешь ввиду делать скриншот тестирование mandatory?

У меня в десяти тестах где-то используется скриншот тестирование,лежит все в общем репозитории в отдельной папке  , тесты гоняются на  CI . Елемент на который ты делаешь скриншот должен быть железно стабильным и не падать.  Тесты делать обязательными можно только тогда ,когда сами разработчики могут их глянуть и тесты стабильные ( чего добиться очень тяжело, потому что у нас постоянно эксперименты разные и все меняется ) . По этому у нас тесты не обязательный шаг для того,что бы разработчик вмерджил ПР.  Однако тест результаты обязательно просматривают . Поддерживает каждый свои скриншоты сам ( у нас несколько департаментов ) , я смотрю логи уже на CI всех тестов и мониторю, плюс делаю код ревью остальных команд. Вывод : если у тебя небольшая пачка тестов  и ты сам их поддерживаешь - можешь впиливать,  но имхо - тесты как quality gate  должно быть не на уровне блокера к ПР а разработчик должен сам видеть в гите ,что у него тесты красные и как минимум посмотреть результаты и пингануть ответственного QA из его команды или вообще. Я своих так приучил

Картинки мержить тяжело)

1. ПР - это продакшен?
2. Какая система наказаний за поломанную ветку?
3. какой средний уровень команды?

ПР = PR = Pull Request
вероятнее всего

1. PR - это пулл реквест.
2. Если разработчик вмерджил сломанный код - он откатывает изменения , делает постмортем и публично выступает на собрании девелоперов в пятницу.
3. Не ниже мидла

Скрины в репе фронта? Или у вас монорепа? Кто обновляет скрины, если заехало валидное изменение? Этот процесс как-то автоматизирован?

Да, оно у нас щас не даёт пиарам фронта мёржиться

У нас не совсем так ) Под скрины попадают виджеты, которые нагружены графиками, данными и настройками. Именно за них контора и получает деньги, девы часто что-то факапят из-за этого эти тесты и появились. Щас их пока чуть больше 50. Тесты реально стабильные, к этому вопросов нет. Девы сами результаты не смотрят. И даже когда я им говорю, что они нафакапили - не верят пока не скину скрин с выделенной строкой в .css и скрин с аппки где конкретно та строчка заафектила юай. Так что отдавать девам анализ - не вариант. Потому же эти тесты и блочат пиары, т.к. девы всё время до последнего рассказывают, что то не они, пока носом не ткнёшь (не все, конечно, но большинство).

Скрины лежат у меня в репе и когда происходит валидное изменение, то мы мёржим красные тесты с моим апрувом и сразу после этого я меняю референс. Это не нравится менеджеру. Он хочет мёржить только зелёное. Выход - положить референс в дев репозиторий. Но этого не хотят девы (оно им там лишнее :)). + есть проблема, что в случае валидных изменений, нужно заранить тесты в CI, получить результаты, поменять референс и заранить всё по второму кругу. Тоже так себе получается.