Вообще у нас реализация была, как выше Роман написал.

надеялся на более простую реализацию и общий отчетик аллюр в джобе=)

ладно, спасибо, буду свой jenkinsfile ковырять

👌

Нет бота против спама(

Добрый вечер! Ребят, подскажите, как у вас организовано визуальное тестирование на проектах? Велик соблазн выкинуть такие ассерты, как например:

assertThat(waitForElementPresent(blockFeedItemSubTitle,
       "blockFeedItemSubTitle not present!", 15)
       .getAttribute("text")).isEqualTo("Alex · Just now");

И вместо этого воткнуть сравнение скриншота с эталоном.
Но не уверен, что это будет правильно. Понятное дело, что на одной странице может быть 10 однообразных тестов, и вполне вероятно, что в этом случае каждый тест проверять скриншотом нет смысла (можно проверить, например, только первый, а в остальных делать обычные ассерты). В целом хотелось бы узнать, в каких случаях нужно применять тестирование скриншотами, а в каких тестирование ассертами

Обычно зависит от того на сколько динамичный проект - если интерфейс заметно меняется каждую неделю - то тестирование скриншотами может вызывать боль, потому что постоянно надо переделывать эталоны, а если интерфейс не меняется и продукт на стадии медленной разработки или поддержки - то скриншоты это изи способ быстро написать тесты )

и в тестировании скриншотами есть свои плюсы потому что ассертами все равно проверяем не все, а скриншот обнаружит любые изменения

вот об этом одном минусе я как раз и думал, и похоже он перечеркивает все плюсы. Но и вовсе отказываться от визуальных проверок похоже нельзя, как минимум один раз страничку или компонент проверить надо визуально

да, попробуйте сделать несколько таких тестов для самых критичных страниц и если все ок - можно постепенно увеличивать число тестов )

ассерты которые вы указали стоит убрать с е2е тестов
такое должно быть проверено на компонентном уровне react test utils или подобное
на счет сраницу как минимум раз скриншотить - считаю так и есть
цсс проверить другим способом никак

всем спасибо!

можно именно этот компонент и проверять. остальное отрезать.

Если будешь делать сравнение скриншотов могу поделится своим опытом
Перед проверкой скриншот кидать в папку и называть так-же как и шаблон
если тест прошел, скрин из папки удаляется если упал - остается
логику можно повесить на какой-нибудь лисенер
Дальше содержимое папки отправляется на проверку тому кто отвечает за UI
он смотрит и если  видит что тест упал из-за изменения в верстке то оставляет скриншот
если из-за какой-то ошибки то удаляет. Соответственно все оставшиеся скриншоты сливаются в папку шаблонов
и сами становятся новыми шаблонами.

благодарю!

все кто хорош в математике, хелп.

Покупатель купил яблоки по цене $a и груши по цене $b потратив ровно $c (a, b, c вводится пользователем).
нужно найти кол-во a,b

помогите с уравнением

Прорал

все верно, QA - quantity assistance

Теперь в ИТ похоже входят минуя школу. Прямо из детсада

может пятница?