Думаю, что все сравнение с этими инструментами нет смысла пытаться впихнуть в один комментарий, но попробую сильно сократить
Если говорить именно про автогенерацию скриншотных тестов по сторибукам, то я не видел такую реализацию от Playwright (но не исключаю, что кто-то из комьюнити мог что-то похожее сделать). Кроме генерации тестов по сторям, testplane позволяет дополнительно дописать своих кастомных тестов для каждой стори. Или добавить набор глобалов, с помощью которых для одной стори будет сгенерировано сразу несколько тестов (например, для тестирования темной и светлой темы). Можно тестировать как локально поднятый, так и удаленный сторибук. И всё это с минимальной конфигурацией
Если говорить про более глобальные вещи относительно скриншотов, то в testplane своя реализация скриншотного сравнения, которая работает быстрее и точнее. А наш отчет просто лучше заточен под работу со скриншотными тестами - есть различные типы сравнения диффов, подсветка диффов по клику, принятие скриншотов по кнопке прямо из отчета.
Если затронуть тему поддержки браузеров, то playwright и cypress поддерживают только CDP, когда testplane поддерживает и CDP, и webdriver, что позволяет сильно расширить набор браузеров для тестирования (например, можно запускать тесты на Android в мобильных браузерах). Но если вам достаточно для тестирования CDP, то, вероятно, для вас это не будет аргументом
Также можно запустить тест условного веб-приложения (можно назвать UI-тесты), мокать данные и делать скриншоты в это время
да, сам testplane конечно поддерживает не только скриншотное тестирование сторибуками - ассертные скриншоты доступны в любом виде. Он поддерживает e2e, интеграционные тесты, компонентные тесты на React или просто клиентские unit-тесты, которые запустятся в браузере. Просто в рамках этой статьи затрагивается только скриншотное тестирование
есть несколько разных подходов. Самый простой - это использование удаленного грида (browserStack, SauceLabs или свой кастомный). При разработке теста можно использовать локальный браузер, а для финального обновления скриншотов используется уже удаленный грид
Также, можно запустить все скриншотные тесты в CI (там они ожидаемо упадут с диффом), а потом скачать отчет и положить его в ваш сервис. Затем с помощью команды `npx testplane gui` открыть интерфейс и обновить скриншоты. В этом случае локально тесты перезапускать не нужно - отчет подхватит данные из CI-ного прогона (как будто вы уже прогнали все эти тесты) и останется только прожать кнопку Accept. Ну и потом закоммитить эти изменения
Можно еще всегда запускать тесты в докер-контейнере, в котором всегда окружение будет одинаковое. Но кажется, что такой способ самый неудобный из всех.
Во внутренней инфраструктуре Яндекса есть возможность обновлять скриншоты прямо из PR - в отчете отмечаются скриншоты для обновления и сразу коммитятся в PR прямо из отчета. Но мы пока не придумали как вытащить такую логику наружу для GitHub
Думаю, что все сравнение с этими инструментами нет смысла пытаться впихнуть в один комментарий, но попробую сильно сократить
Если говорить именно про автогенерацию скриншотных тестов по сторибукам, то я не видел такую реализацию от Playwright (но не исключаю, что кто-то из комьюнити мог что-то похожее сделать). Кроме генерации тестов по сторям, testplane позволяет дополнительно дописать своих кастомных тестов для каждой стори. Или добавить набор глобалов, с помощью которых для одной стори будет сгенерировано сразу несколько тестов (например, для тестирования темной и светлой темы). Можно тестировать как локально поднятый, так и удаленный сторибук. И всё это с минимальной конфигурацией
Если говорить про более глобальные вещи относительно скриншотов, то в testplane своя реализация скриншотного сравнения, которая работает быстрее и точнее. А наш отчет просто лучше заточен под работу со скриншотными тестами - есть различные типы сравнения диффов, подсветка диффов по клику, принятие скриншотов по кнопке прямо из отчета.
Если затронуть тему поддержки браузеров, то playwright и cypress поддерживают только CDP, когда testplane поддерживает и CDP, и webdriver, что позволяет сильно расширить набор браузеров для тестирования (например, можно запускать тесты на Android в мобильных браузерах). Но если вам достаточно для тестирования CDP, то, вероятно, для вас это не будет аргументом
да, сам testplane конечно поддерживает не только скриншотное тестирование сторибуками - ассертные скриншоты доступны в любом виде. Он поддерживает e2e, интеграционные тесты, компонентные тесты на React или просто клиентские unit-тесты, которые запустятся в браузере. Просто в рамках этой статьи затрагивается только скриншотное тестирование
спасибо за фидбек. мы обязательно обратим внимание на это и постараемся сделать контрастность, подходящую даже самым требовательным пользователям ;)
есть несколько разных подходов. Самый простой - это использование удаленного грида (browserStack, SauceLabs или свой кастомный). При разработке теста можно использовать локальный браузер, а для финального обновления скриншотов используется уже удаленный грид
Также, можно запустить все скриншотные тесты в CI (там они ожидаемо упадут с диффом), а потом скачать отчет и положить его в ваш сервис. Затем с помощью команды `npx testplane gui` открыть интерфейс и обновить скриншоты. В этом случае локально тесты перезапускать не нужно - отчет подхватит данные из CI-ного прогона (как будто вы уже прогнали все эти тесты) и останется только прожать кнопку Accept. Ну и потом закоммитить эти изменения
Можно еще всегда запускать тесты в докер-контейнере, в котором всегда окружение будет одинаковое. Но кажется, что такой способ самый неудобный из всех.
Во внутренней инфраструктуре Яндекса есть возможность обновлять скриншоты прямо из PR - в отчете отмечаются скриншоты для обновления и сразу коммитятся в PR прямо из отчета. Но мы пока не придумали как вытащить такую логику наружу для GitHub