Интересный вопрос.
Почти все проекты — аутсорс, оплата проводится по выставляемым счетам. Потеря денег заказчика не сказывается на величине оплаты. В крайнем случае приходится делать скидку по счетам.

Если считать деньгами заказчика, то дешевле проплатить ui-шные:  меньше денег мимо кармана по сравнению с факапами и ловим меньше бугурта со стороны аудитории сайтов (инет-магазинов)

upd. сорян, забыл добавить, что описывал конкретно взятый случай именно в текущей компании с текущими заказчиками :)

идея простая, делать проверки на минимально возможном уровне. Если ты можешь словить багу при юнит тестах - напиши юнит тест. Если проверка может выявить уязвимость только на UI флоу - пиши UI тест.
Но определить это, да еще во время разработки получается сложно и не всегда, требует ресурсов и коллаборации всех ролей, а с этим туго

не соглашусь, все зависит от многих факторов

плюс ты мыслишь так, как будто у тебя немного тестов - пусть будет 300-400. Флаки пару процентов и ок. А когда UI тестов 1-3к, то все - тебе жопа.

Бездумно покрывать юнитами или интеграционными ради % покрытия - зашквар и не эффективно конечно

Мы вот 4й квартал 2019го пытаемся сколлаборироваться

я бы сказал что это очень сложно, за то потом приятнее работать на порядок

У меня флаки 0.2%

Чтобы проверить их - 1-3 минуты. Огурец же)

1. Оптимизировать тесты и/или расширить инфраструктуру для автотестов.
2. Каждый случай нужно рассматривать в отдельности: и со стороны теста, и со стороны реализации. Ну и смириться с тем, что браузерные в среднем менее стабильны, чем не-браузерные.
3. После открытия пуллреквеста, автоматом собирать пуляемую ветку на энном промежуточном стенде. Отследить применение актуального кода на соответствующем стенде. Пустить ui-шные по стенду. Связать-настроить пайпланы, дабы результаты прогона автотестов светились в пулл-реквесте соответствующей ветки — настроили такое пока только со статик анализом (без промежуточного стенда, ага).
4. Не судьба.

Да, на это всё нужно деньги и время. Возможно, ваше начальство, как и моё, не хочет тратиться

1. Тесты бегают 5 минут. Это очень быстро.
2. ...
3. У нас сейчас при переводе таски в тест - собирается стенд, прогоняются тесты. Можно при необходимости руками запустить.

В 3м пункте имелось ввиду, что тесты долгие, на каждый чих дорого запускать

И юниты решат эту проблему

у вас пулл-реквесты на кодревью висят не дольше, чем 5минут? :) я к тому, что автотесты успеют выполниться за то время, пока дойдут руки глянуть-слить пулл;

ннепонятно, почему в первом пункте 5минут —  быстро, а к третьему пункту 5мин стало долго

5 минут - это релизный набор. Только на релизах гоняем.
В дев окружении весь набор, это 15-20 минут без учёта сборки стенда

Гонять тесты на измененный функционал - пока не вижу, как это можно сделать.

Всем привет, такой вопрос. Ecть проект достаточно большой на Ангуларе первом, весь UI покрыт тестами на Protractor 4 версии Jasmine. Планируеться переписать весь UI на реакт. Что в таком случаи делать? оставлять протрактор или взять что-то другое и переписать с нуля. Тесты ранятсяя часов 8. Мне предлагаю перейти как второй AQA на этот проект (Я месяцев 5 ковыряю Протрор 5.4.2 Jasminе, typescript) Вот просто не знаю или есть мне смысл переходить на этот проект, потому со старым протрактором не очень хочеться работать, и пока не понятно какое приймут решение о фреймворке

в чем твой вопрос? ты же не влияешь на решение о том, какой фреймворк будет, и ты еще сам не знаешь какой выберут

Не влияю на решение. Ну хочеться знать какое решение было бы логичным. Можно ли оставить протрактор для Реакта или лучше все переписывать на каком-то другом фреймворке? (Просто если весь сушествующий функционал покрыл, логиченее наверное оставить протрактор и проапдейтить тесты под реакт). Что скажете?