Для скриншот тестов есть билд в CI (teamcity). Билд автоматически запускается на каждой ветке. В нем сначала поднимается витрина компонентов (react-styleguidist), а потом playwright заходит на страницы компонентов и фоткает все примеры. Внутри @playwright/test есть хелпер toMatchSnapshot который сравнивает скриншоты и в случае если они не совпадают создает картинку с дифом. В playwright v1.16.0 завезли html репортер, мы еще не успели его прикрутить и смотрим дифы картинок в артефактах в CI если что-то пошло не так.
Для обновления скриншотов в CI предусмотрен отдельный билд, который можно запустить на нужной ветке. Это те же тесты, но с флагом, который обновляет скриншоты при необходимости. Далее билд с новыми картинками делает комит в ветку. В пул-реквестах видно что поменялось тк картинки хранятся рядом с кодом под git lfs.
При необходимости, скриншотные тесты и обновление скриншотов можно запустить локально в докере для всех компонентов или для конкретного.
Руками тесты писать не нужно. Новые тесты автоматически появляются после добавления в витрину нового примера или компонента. Для этого сделан небольшой скрипт, о котором речь в статье. Также есть возможность отключить тесты для компонента/примера.
В статье не говорится что ежедневные релизы нужны всем, а скорей пытается ответить на вопрос как к ним прийти если это нужно. Возможность быстро проверять гипотезы и реагировать на изменение рынка это конкурентное преимущество, для некоторых бизнесов, на мой взгляд.
И ведь действительно: в погоне за частотой релизов и скоростью вы неизбежно их создаёте, а потом героически преодолеваете.
Гонки нет, это совершенно будничный процесс. Если изменения готовы, то незачем ждать условного релиза через месяц, если можно вылить их сейчас. У нас каждый день есть небольшие улучшения которые выкатываются на продакшн.
Если бизнес оценивает KPI в кол-ве задач это грустно. Но это не наш случай.
К сожалению, сборки для продакшена не избежать из-за проблемы о которой говорите вы, минификации и прочих оптимизаций. Но можно настроить сборку в которой таргет будут ES модули. Приложение нужно будет собрать, но только один раз для релиза.
Который парсит ваши шаблоны прямо в браузере.
Это также решается продакшен сборкой и использованием babel-plugin-htm
Я не совсем уверен, что вы понимаете значение слова "проприетарный".
Вы правы, неудачное использование. В этом контексте имелось ввиду что JSX разработала компания для своих нужд и не было намерения сделать из этого стандарт который работает в браузере.
Что?
Примеры, приведенные в документации angular и react, не запустятся в браузере без инструментов сборки.
С Vue поторопился такие выводы делать, спасибо что отметили!
Да, конечно! Большинство скриншот тестов, делаем с помощью playwright и @playwright/test.
Для скриншот тестов есть билд в CI (teamcity). Билд автоматически запускается на каждой ветке. В нем сначала поднимается витрина компонентов (react-styleguidist), а потом playwright заходит на страницы компонентов и фоткает все примеры. Внутри @playwright/test есть хелпер toMatchSnapshot который сравнивает скриншоты и в случае если они не совпадают создает картинку с дифом. В playwright v1.16.0 завезли html репортер, мы еще не успели его прикрутить и смотрим дифы картинок в артефактах в CI если что-то пошло не так.
Для обновления скриншотов в CI предусмотрен отдельный билд, который можно запустить на нужной ветке. Это те же тесты, но с флагом, который обновляет скриншоты при необходимости. Далее билд с новыми картинками делает комит в ветку. В пул-реквестах видно что поменялось тк картинки хранятся рядом с кодом под git lfs.
При необходимости, скриншотные тесты и обновление скриншотов можно запустить локально в докере для всех компонентов или для конкретного.
Руками тесты писать не нужно. Новые тесты автоматически появляются после добавления в витрину нового примера или компонента. Для этого сделан небольшой скрипт, о котором речь в статье. Также есть возможность отключить тесты для компонента/примера.
В статье не говорится что ежедневные релизы нужны всем, а скорей пытается ответить на вопрос как к ним прийти если это нужно. Возможность быстро проверять гипотезы и реагировать на изменение рынка это конкурентное преимущество, для некоторых бизнесов, на мой взгляд.
Гонки нет, это совершенно будничный процесс. Если изменения готовы, то незачем ждать условного релиза через месяц, если можно вылить их сейчас. У нас каждый день есть небольшие улучшения которые выкатываются на продакшн.
Если бизнес оценивает KPI в кол-ве задач это грустно. Но это не наш случай.
Добрый день! Есть дашборды с продуктовыми метриками, гипотезы проверяются а/б тестами.
К сожалению, сборки для продакшена не избежать из-за проблемы о которой говорите вы, минификации и прочих оптимизаций. Но можно настроить сборку в которой таргет будут ES модули. Приложение нужно будет собрать, но только один раз для релиза.
Это также решается продакшен сборкой и использованием babel-plugin-htm
Вы правы, неудачное использование. В этом контексте имелось ввиду что JSX разработала компания для своих нужд и не было намерения сделать из этого стандарт который работает в браузере.
Примеры, приведенные в документации angular и react, не запустятся в браузере без инструментов сборки.
С Vue поторопился такие выводы делать, спасибо что отметили!