Спасибо за совет, действительно дельный. Следующим шагом выберу и прикручу какой-то из предложенных плагинов по репортингу.
Заюзать их действительно будет красивее и, надеюсь, проще.
Относительно гусей — вы же понимаете, что это не боевой отчет и на их месте можно установить лого проекта) Или убрать полностью, картинка только для примера.
По поводу доработок конфигурации/архитектуры: действительно, если бы стало падать более половины тестов — это было бы правильным решением. В моем случае тестов стало валиться в 2 раза больше, но не больше половины. Т.е. из ситуации 300 (285/15) я попал в ситуацию 300 (270/30).
А что касается сокрытия реальных проблем — уже писал выше, применять стоит с оговорками. Моя цель — не зеленый репорт. И применение данного функционала на моем проекте оправдано, на другом — может быть не допустимо. Все зависит от того, сколько компонентов входит в ваш тестовый фреймворк. В нашем случае UI-тесты — не единственный барьер, который защищает прод от багов.
согласен, идея тоже правильная. наверное, применять данный функционал стоит с оговорками и пониманием. например, у нас на проекте задействовано большое кол-во api и собственных прослоек, что в сумме значительно повышает кол-во возможных точек отказа.
потому на текущем этапе я предпочитаю их переопросить, вдруг они передумали и решили работать)
но с вами согласен, палка двух концов.
Заюзать их действительно будет красивее и, надеюсь, проще.
Относительно гусей — вы же понимаете, что это не боевой отчет и на их месте можно установить лого проекта) Или убрать полностью, картинка только для примера.
По поводу доработок конфигурации/архитектуры: действительно, если бы стало падать более половины тестов — это было бы правильным решением. В моем случае тестов стало валиться в 2 раза больше, но не больше половины. Т.е. из ситуации 300 (285/15) я попал в ситуацию 300 (270/30).
А что касается сокрытия реальных проблем — уже писал выше, применять стоит с оговорками. Моя цель — не зеленый репорт. И применение данного функционала на моем проекте оправдано, на другом — может быть не допустимо. Все зависит от того, сколько компонентов входит в ваш тестовый фреймворк. В нашем случае UI-тесты — не единственный барьер, который защищает прод от багов.
потому на текущем этапе я предпочитаю их переопросить, вдруг они передумали и решили работать)
но с вами согласен, палка двух концов.