Ключевые моменты
- Shadow DOM инкапсулирует стили и DOM, делая классические подходы визуального тестирования частично слепыми
- Инструменты, инспектирующие «обычный» DOM, не видят элементов внутри Shadow DOM без специальной адаптации
- Структурный подход, который судит о странице по её итоговому виду в браузере, работает сквозь Shadow DOM, поскольку опирается на финальный результат рендеринга
- Слоты, CSS custom properties и наследование стилей создают сложные взаимодействия, которые может верифицировать только анализ реального рендеринга
MDN определяет Web Components как «набор технологий, позволяющих создавать переиспользуемые пользовательские HTML-элементы, функциональность которых инкапсулирована и изолирована от остального кода» (MDN Web Docs, Web Components).
За этим определением скрывается тихая революция. Web Components — уже не экспериментальная диковинка. В 2026 году все основные браузеры поддерживают их нативно. Фреймворки Lit, Stencil и FAST используют их как основу. Такие компании, как Adobe (Spectrum Web Components), SAP (UI5 Web Components) и ING Bank (Lion Web Components), строят на этой технологии целые дизайн-системы.
Однако визуальное тестирование Web Components остаётся слепым пятном для большинства команд. Причина сводится к двум словам: Shadow DOM.
Главное на одной странице — определение, автоматизация без кода, выбор инструмента: Автоматизированное регрессионное тестирование без кода.
Shadow DOM больше не должен быть слепым пятном вашего QA. Сравнивайте реальный визуальный рендеринг ваших Web Components без кода, прямо на вашей машине и без банковской карты. Попробовать Delta-QA бесплатно →
Что Shadow DOM меняет для визуального тестирования
Обычно весь DOM на вашей странице — единое дерево. CSS-селекторы применяются ко всем элементам. Инструменты тестирования могут обходить всю структуру.
Shadow DOM ломает это допущение. Он создаёт изолированное поддерево DOM, прикреплённое к хост-элементу, с собственными стилями. Внешние CSS-селекторы не могут достичь внутренних элементов. Скрипты, обходящие DOM с помощью querySelector, не видят, что находится внутри shadow.
Именно в этом и заключается назначение Shadow DOM: инкапсуляция. Ваши стили не «утекают» наружу, внешние стили не «загрязняют» внутреннее пространство. Это фича, а не баг.
Но для визуального тестирования эта инкапсуляция — стена. И большинство инструментов тестирования не знают, как её преодолеть.
Три механизма, усложняющих всё
Инкапсуляция стилей
Внутри Shadow DOM стили локальны. Селектор .button в вашем Shadow DOM нацелен только на элементы .button в этом конкретном Shadow DOM. Обратное также верно: ваши глобальные стили не применяются внутри Shadow DOM.
Для визуального тестирования это означает, что нельзя судить о стиле компонента, опираясь только на глобальные таблицы стилей. Каждый компонент — это отдельный мир со своими правилами.
Слоттинг и проекция контента
Слоты позволяют пользователям компонента вставлять контент внутрь Shadow DOM. Компонент определяет слоты (<slot>), а контент из родительского элемента «проецируется» в них.
Для визуального тестирования: слоттированный контент принадлежит light DOM, но отображается в контексте Shadow DOM. Он наследует некоторые стили Shadow DOM, но технически остаётся в light DOM. Эта двойственность создаёт ситуации, когда инструмент тестирования видит элемент в light DOM, но не понимает его реальный визуальный контекст.
CSS Custom Properties
CSS custom properties (CSS-переменные) — единственный стандартный CSS-механизм, пересекающий границу Shadow DOM. Если вы определяете --primary-color: blue на хост-элементе, эта переменная доступна внутри Shadow DOM.
Это основной механизм темизации для Web Components. Проблема для визуального тестирования: эффективное значение custom property зависит от полной CSS-каскада. Единственная сущность, которая корректно разрешает эту зависимость — сам браузер.
Почему классические подходы не работают
Инструменты на основе DOM
Многие инструменты тестирования инспектируют DOM для понимания структуры страницы. Столкнувшись с Shadow DOM, они упираются в стену: внутренние элементы не видны через стандартные DOM API. Большинство инструментов создавались в эпоху, когда DOM был единым плоским деревом.
Попиксельное сравнение
Подход со скриншотами работает... на поверхности. Он захватывает то, что отображает браузер — будь то Shadow DOM или нет. Но он не понимает структуру. Если Web Component меняет рендеринг из-за изменения унаследованной custom property, попиксельное сравнение обнаруживает изменение, но не может определить причину.
CSS-селекторы в тестах
Если вы пишете тесты, верифицирующие стили через CSS-селекторы, ваши селекторы не проходят сквозь Shadow DOM. Можно обойти это, выстроив цепочку обращений к shadowRoot, но это делает тесты хрупкими и зависимыми от внутренней структуры компонента — именно от того, от чего инкапсуляция Shadow DOM призвана защитить.
Структурный подход: почему он проходит сквозь Shadow DOM
Структурный подход к визуальному тестированию элегантно обходится с проблемой Shadow DOM. Он не пытается угадать по исходному коду, что отображается. Он судит о странице по её итоговому виду в браузере — по тому результату, который реально увидит пользователь.
Когда браузер рендерит элемент — будь то в light DOM, Shadow DOM или проецированный через слот — он разрешает полный каскад и выдаёт конкретный итоговый вид. Цвет фона — это уже не «var(--surface-color)», а конкретный «rgb(30, 30, 30)». Размер шрифта — уже не «1.2em», а вполне определённый «19.2px».
Опираясь на этот итоговый вид, движок судит о каждом видимом элементе по его финальному отображению в браузере. Ему не нужно понимать инкапсуляцию Shadow DOM, разрешение custom properties или правила слоттинга. Браузер уже выполнил всю эту работу — остаётся лишь сравнить то, что видно на экране.
Это фундаментальное отличие. Вместо попыток воспроизвести логику браузера (и провала с Shadow DOM), детерминированный движок отрисовывает обе страницы в реальном браузере и сравнивает визуальный результат — то, что в итоге видит человеческий глаз.
Shadow DOM делает классические инструменты слепыми? Проверьте, как Delta-QA справляется с вашими Web Components — бесплатно, без кода и без банковской карты. Попробовать Delta-QA бесплатно →
Конкретные примеры, где это имеет значение
Сломанная темизация
Ваша дизайн-система предоставляет --button-bg для настройки цвета кнопок. Команда обновляет основную тему и переименовывает переменную в --btn-background. Все кнопки в Shadow DOM теряют свой кастомный цвет и откатываются к значениям по умолчанию.
Структурный тест немедленно отмечает изменение цвета кнопки — ровно так, как его заметил бы человеческий глаз. Попиксельный тест тоже обнаруживает его, но сообщает об изменении без объяснения причины. DOM-тест ничего не обнаруживает, потому что компонент структурно идентичен.
Неправильно стилизованные слоты
Карточечный компонент использует слот для заголовка. Заголовок предоставляется родителем как <h3>. Кто-то меняет глобальные стили <h3>, не осознавая, что они применяются и к слоттированным заголовкам в карточках — потому что слоттированные элементы наследуют стили light DOM для свойств, не определённых в Shadow DOM.
Движок судит о <h3> по его итоговому виду в реальном контексте отображения (внутри слота) и отмечает изменение размера или начертания — ровно то, что заметил бы человеческий глаз.
Вложенные компоненты
Диалоговый компонент содержит компонент формы, который содержит компоненты полей ввода. Три уровня вложенного Shadow DOM. Изменение custom property на уровне диалога должно распространиться через все три уровня.
Движок судит о каждом видимом элементе на любом уровне по его итоговому виду в браузере, не обращая внимания на глубину вложенности. Браузер разрешил каскад — движок сравнивает то, что в итоге появилось на экране.
Web Components и дизайн-системы: стратегическая необходимость
Web Components — технология выбора для современных дизайн-систем. Web Component работает с React, Angular, Vue или вообще без фреймворка. Это максимальная интероперабельность.
Но эта интероперабельность создаёт серьёзную задачу для визуального тестирования. Ваша дизайн-система на Web Components используется множеством команд в множестве приложений с разными CSS-контекстами. Визуальный баг в базовом компоненте распространяется повсюду.
Визуальное тестирование дизайн-системы на Web Components — не опция. Это обеспечение качества для всех зависимых команд. И это обеспечение должно работать сквозь Shadow DOM, со слотами, с custom properties.
Структурный подход на сегодняшний день — единственный, который закрывает все эти требования без технических акробатик.
Как Delta-QA работает с Web Components
В основе Delta-QA — детерминированный движок визуального сравнения. Он судит о каждом видимом элементе по его итоговому виду в браузере — в light DOM, Shadow DOM или проецированном через слот. Никакой специальной конфигурации для Web Components не требуется — инструмент обрабатывает их как любой другой отрендеренный элемент.
В частности, Delta-QA верифицирует контраст текста внутри Shadow DOM, обнаруживает несогласованность отступов между компонентами и выявляет регрессии темизации при изменении значения custom property. Всё это — без написания тестов, без специфичных CSS-селекторов, без явного обращения к shadowRoot.
Практические советы по визуальному тестированию Web Components
Сначала тестируйте компоненты изолированно
Перед тестированием полных страниц протестируйте каждый компонент в изолированной среде (Storybook или демо-страница). Верифицируйте состояния (по умолчанию, hover, focus, disabled, error) и варианты (размеры, цвета, светлая/тёмная темы).
Проверяйте точки интеграции
Самые коварные визуальные баги появляются в точках интеграции: там, где light DOM встречается с Shadow DOM, где один компонент вложен в другой, где custom properties пересекают границы.
Отслеживайте custom properties
Ведите инвентарь ваших темизационных custom properties. Детерминированный движок сам отмечает любое видимое изменение оформления независимо от его причины — то, что заметил бы человеческий глаз.
Интегрируйте визуальное тестирование в пайплайн публикации
Каждая новая версия Web Component должна проходить автоматизированное визуальное тестирование перед публикацией. Регрессия в базовом компоненте имеет разрушительный мультипликативный эффект.
FAQ
Shadow DOM мешает автоматизированному визуальному тестированию?
Нет, но он мешает определённым подходам к визуальному тестированию. Инструменты, инспектирующие DOM, не видят элементы Shadow DOM без специальной адаптации. Однако инструменты, которые судят о странице по её итоговому виду в браузере (структурный подход), проходят сквозь Shadow DOM без затруднений, поскольку опираются на финальный результат рендеринга.
Как слоты влияют на визуальное тестирование Web Components?
Слоты создают двойственность: слоттированный контент принадлежит light DOM, но отображается в визуальном контексте Shadow DOM. Унаследованные стили поступают с обеих сторон. Эффективный инструмент визуального тестирования должен верифицировать реальный внешний вид элемента в его финальном контексте отображения, а не его позицию в дереве DOM. Структурный подход справляется с этим естественно.
Нужны ли специальные визуальные тесты для Web Components?
Нет, если ваш инструмент использует структурный подход. Правила визуального качества (контраст, отступы, выравнивание, согласованность) применяются одинаково ко всем элементам независимо от позиции в DOM. Вам не нужны «специальные тесты для Web Components» — вам нужен инструмент, который работает везде.
Требует ли Delta-QA специальной конфигурации для Web Components?
Нет. Delta-QA отрисовывает страницу в реальном браузере и сравнивает итоговый вид всех видимых элементов независимо от позиции в DOM. Элементы Shadow DOM обрабатываются точно так же, как любые другие. Никаких специальных селекторов, никакой конфигурации shadowRoot, никаких скриптов доступа.
Создают ли Web Components больше визуальных регрессий, чем традиционные компоненты?
Не по своей природе, но регрессии сложнее обнаружить классическими инструментами. Инкапсуляция Shadow DOM скрывает изменения от неподготовленных инструментов. Кроме того, взаимодействия между custom properties, наследованием CSS и слоттингом создают тонкие цепочки зависимостей, которые автоматизированное визуальное тестирование лучше подготовлено мониторить, чем человек.
Какие фреймворки Web Components совместимы со структурным визуальным тестированием?
Структурный подход не зависит от фреймворка. Используете ли вы Lit, Stencil, FAST или нативные Web Components — браузер выдаёт один и тот же итоговый вид. Delta-QA работает со всеми фреймворками Web Components без различий, поскольку судит о странице по результату рендеринга, а не по исходному коду компонента.
Готовы тестировать ваши Web Components, не сражаясь с Shadow DOM? Наведите Delta-QA на вашу страницу и запустите первое визуальное сравнение — бесплатно и без банковской карты. Попробовать Delta-QA бесплатно →