Skip to main content

Тестирование снимков

Обзор​

С помощью тестирования снимков в Playwright вы можете проверять дерево доступности страницы по заранее определенному шаблону снимка.

await page.goto('https://playwright.dev/');
await expect(page.getByRole('banner')).toMatchAriaSnapshot(`
  - banner:
    - heading /Playwright enables reliable end-to-end/ [level=1]
    - link "Get started"
    - link "Star microsoft/playwright on GitHub"
    - link /[\\d]+k\\+ stargazers on GitHub/
`);

Тестирование утверждений vs Тестирование снимков​

Тестирование снимков и тестирование утверждений служат разным целям в автоматизации тестирования:

Тестирование утверждений​

Тестирование утверждений — это целенаправленный подход, при котором вы утверждаете конкретные значения или условия для элементов или компонентов. Например, с помощью Playwright, expect(locator).toHaveText() проверяет, что элемент содержит ожидаемый текст, а expect(locator).toHaveValue() подтверждает, что поле ввода имеет ожидаемое значение. Тесты утверждений специфичны и обычно проверяют текущее состояние элемента или свойства по сравнению с ожидаемым, заранее определенным состоянием. Они хорошо работают для предсказуемых, однозначных проверок, но ограничены в охвате при тестировании более широкой структуры или вариаций.

Преимущества

  • Ясность: Намерение теста явно и легко понять.
  • Специфичность: Тесты сосредоточены на конкретных аспектах функциональности, что делает их более устойчивыми к несвязанным изменениям.
  • Отладка: Ошибки предоставляют целенаправленную обратную связь, указывая непосредственно на проблемный аспект.

Недостатки

  • Многословность для сложных выводов: Написание утверждений для сложных структур данных или больших выводов может быть громоздким и подверженным ошибкам.
  • Затраты на обслуживание: По мере развития кода ручное обновление утверждений может быть трудоемким.

Тестирование снимков​

Тестирование снимков захватывает "снимок" или представление всего состояния элемента, компонента или данных в данный момент, который затем сохраняется для будущих сравнений. При повторном запуске тестов текущее состояние сравнивается со снимком, и если есть различия, тест не проходит. Этот подход особенно полезен для сложных или динамических структур, где ручное утверждение каждой детали было бы слишком трудоемким. Тестирование снимков более широкое и целостное, чем тестирование утверждений, позволяя отслеживать более сложные изменения с течением времени.

Преимущества

  • Упрощает сложные выводы: Например, тестирование визуального компонента может быть утомительным с традиционными утверждениями. Снимки захватывают весь вывод для легкого сравнения.
  • Быстрая обратная связь: Разработчики могут легко заметить непреднамеренные изменения в выводе.
  • Поощряет согласованность: Помогает поддерживать согласованный вывод по мере развития кода.

Недостатки

  • Чрезмерная зависимость: Может возникнуть соблазн принять изменения в снимках, не полностью понимая их, что потенциально скрывает ошибки.
  • Гранулярность: Большие снимки могут быть трудны для интерпретации, когда возникают различия, особенно если незначительные изменения затрагивают большие части вывода.
  • Пригодность: Не идеально для высоко динамичного контента, где выводы часто или непредсказуемо меняются.

Когда использовать​

  • Тестирование снимков идеально для:
    • Тестирования пользовательского интерфейса целых страниц и компонентов.
    • Широких структурных проверок для сложных компонентов пользовательского интерфейса.
    • Регрессионного тестирования для выводов, которые редко меняют структуру.
  • Тестирование утверждений идеально для:
    • Проверки основной логики.
    • Тестирования вычисленных значений.
    • Тонких тестов, требующих точных условий.

Комбинируя тестирование снимков для широких, структурных проверок и тестирование утверждений для конкретной функциональности, вы можете достичь всесторонней стратегии тестирования.

Aria снимки​

В Playwright, aria снимки предоставляют YAML-представление дерева доступности страницы. Эти снимки могут быть сохранены и сравнены позже, чтобы проверить, остается ли структура страницы последовательной или соответствует определенным ожиданиям.

Формат YAML описывает иерархическую структуру доступных элементов на странице, детализируя роли, атрибуты, значения и текстовое содержимое. Структура следует синтаксису, похожему на дерево, где каждый узел представляет доступный элемент, а отступы указывают на вложенные элементы.

Каждый доступный элемент в дереве представлен как узел YAML:

- role "name" [attribute=value]
  • role: Указывает ARIA или HTML роль элемента (например, heading, list, listitem, button).
  • "name": Доступное имя элемента. Строки в кавычках указывают точные значения, /patterns/ используются для регулярных выражений.
  • [attribute=value]: Атрибуты и значения в квадратных скобках представляют конкретные ARIA атрибуты, такие как checked, disabled, expanded, level, pressed или selected.

Эти значения получены из ARIA атрибутов или вычислены на основе HTML семантики. Чтобы исследовать структуру дерева доступности страницы, используйте Chrome DevTools Accessibility Pane.

Сопоставление снимков​

Метод утверждения expect(locator).toMatchAriaSnapshot() в Playwright сравнивает доступную структуру области локатора с заранее определенным шаблоном aria снимка, помогая проверить состояние страницы в соответствии с требованиями тестирования.

Для следующего DOM:

<h1>title</h1>

Вы можете сопоставить его, используя следующий шаблон снимка:

await expect(page.locator('body')).toMatchAriaSnapshot(`
  - heading "title"
`);

При сопоставлении шаблон снимка сравнивается с текущим деревом доступности страницы:

  • Если структура дерева соответствует шаблону, тест проходит; в противном случае он не проходит, указывая на несоответствие между ожидаемыми и фактическими состояниями доступности.
  • Сравнение чувствительно к регистру и сворачивает пробелы, поэтому отступы и разрывы строк игнорируются.
  • Сравнение чувствительно к порядку, что означает, что порядок элементов в шаблоне снимка должен соответствовать порядку в дереве доступности страницы.

Частичное сопоставление​

Вы можете выполнять частичные сопоставления узлов, опуская атрибуты или доступные имена, что позволяет проверять конкретные части дерева доступности без необходимости точных совпадений. Эта гибкость полезна для динамических или несущественных атрибутов.

<button>Submit</button>

aria снимок

- button

В этом примере роль кнопки сопоставлена, но доступное имя ("Submit") не указано, что позволяет тесту пройти независимо от метки кнопки.

Для элементов с ARIA атрибутами, такими как checked или disabled, опуская эти атрибуты, можно сосредоточиться только на роли и иерархии.

<input type="checkbox" checked>

aria снимок для частичного сопоставления

- checkbox

В этом частичном сопоставлении атрибут checked игнорируется, поэтому тест пройдет независимо от состояния флажка.

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

<ul>
  <li>Feature A</li>
  <li>Feature B</li>
  <li>Feature C</li>
</ul>

aria снимок для частичного сопоставления

- list
  - listitem: Feature B

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

Сопоставление с регулярными выражениями​

Регулярные выражения позволяют гибко сопоставлять элементы с динамическим или переменным текстом. Доступные имена и текст могут поддерживать шаблоны регулярных выражений.

<h1>Issues 12</h1>

aria снимок с регулярным выражением

- heading /Issues \d+/

Генерация снимков​

Создание aria снимков в Playwright помогает обеспечить и поддерживать структуру вашего приложения. Вы можете генерировать снимки различными способами в зависимости от вашей настройки тестирования и рабочего процесса.

Генерация снимков с помощью генератора кода Playwright​

Если вы используете Генератор кода Playwright, генерация aria снимков упрощена с его интерактивным интерфейсом:

  • Действие "Assert snapshot": В генераторе кода вы можете использовать действие "Assert snapshot" для автоматического создания утверждения снимка для выбранных элементов. Это быстрый способ захватить aria снимок как часть вашего записанного тестового потока.
  • Вкладка "Aria snapshot": Вкладка "Aria snapshot" в интерфейсе генератора кода визуально представляет aria снимок для выбранного локатора, позволяя вам исследовать, проверять и проверять роли элементов, атрибуты и доступные имена для помощи в создании и проверке снимков.

Обновление снимков с помощью @playwright/test и флага --update-snapshots​

При использовании тестового раннера Playwright (@playwright/test) вы можете автоматически обновлять снимки с помощью флага --update-snapshots, сокращенно -u.

Запуск тестов с флагом --update-snapshots обновит снимки, которые не совпали. Совпадающие снимки не будут обновлены.

npx playwright test --update-snapshots

Обновление снимков полезно, когда изменения в структуре приложения требуют новых снимков в качестве основы. Обратите внимание, что Playwright будет ждать максимального времени ожидания, указанного в конфигурации тестового раннера, чтобы убедиться, что страница стабилизировалась перед созданием снимка. Возможно, потребуется настроить --timeout, если тест достигает тайм-аута при генерации снимков.

Пустой шаблон для генерации снимков​

Передача пустой строки в качестве шаблона в утверждении генерирует снимок на лету:

await expect(locator).toMatchAriaSnapshot('');

Обратите внимание, что Playwright будет ждать максимального времени ожидания, указанного в конфигурации тестового раннера, чтобы убедиться, что страница стабилизировалась перед созданием снимка. Возможно, потребуется настроить --timeout, если тест достигает тайм-аута при генерации снимков.

Файлы патчей снимков​

При обновлении снимков Playwright создает файлы патчей, которые фиксируют различия. Эти файлы патчей могут быть просмотрены, применены и зафиксированы в системе контроля версий, позволяя командам отслеживать структурные изменения с течением времени и обеспечивать, чтобы обновления соответствовали требованиям приложения.

Способ обновления исходного кода можно изменить с помощью флага --update-source-method. Доступно несколько вариантов:

  • "patch" (по умолчанию): Генерирует унифицированный файл diff, который можно применить к исходному коду с помощью git apply.
  • "3way": Генерирует маркеры конфликтов слияния в вашем исходном коде, позволяя вам выбрать, принимать ли изменения.
  • "overwrite": Перезаписывает исходный код новыми значениями снимков.
npx playwright test --update-snapshots --update-source-mode=3way

Снимки как отдельные файлы​

Чтобы сохранить ваши снимки в отдельном файле, используйте метод toMatchAriaSnapshot с опцией name, указывая расширение файла .aria.yml.

await expect(page.getByRole('main')).toMatchAriaSnapshot({ name: 'main.aria.yml' });

По умолчанию снимки из тестового файла example.spec.ts размещаются в каталоге example.spec.ts-snapshots. Поскольку снимки должны быть одинаковыми для всех браузеров, сохраняется только один снимок, даже если тестирование проводится с несколькими браузерами. Если вы хотите, вы можете настроить шаблон пути снимка с помощью следующей конфигурации:

export default defineConfig({
  expect: {
    toMatchAriaSnapshot: {
      pathTemplate: '__snapshots__/{testFilePath}/{arg}{ext}',
    },
  },
});

Использование метода Locator.ariaSnapshot​

Метод locator.ariaSnapshot() позволяет программно создавать YAML-представление доступных элементов в области локатора, что особенно полезно для динамической генерации снимков во время выполнения теста.

Пример:

const snapshot = await page.locator('body').ariaSnapshot();
console.log(snapshot);

Эта команда выводит aria снимок в пределах области указанного локатора в формате YAML, который вы можете проверить или сохранить по мере необходимости.

Примеры дерева доступности​

Заголовки с атрибутами уровня​

Заголовки могут включать атрибут level, указывающий их уровень заголовка.

<h1>Title</h1>
<h2>Subtitle</h2>

aria снимок

- heading "Title" [level=1]
- heading "Subtitle" [level=2]

Текстовые узлы​

Отдельные или описательные текстовые элементы появляются как текстовые узлы.

<div>Sample accessible name</div>

aria снимок

- text: Sample accessible name

Встроенный многострочный текст​

Многострочный текст, такой как абзацы, нормализуется в aria снимке.

<p>Line 1<br>Line 2</p>

aria снимок

- paragraph: Line 1 Line 2

Ссылки​

Ссылки отображают свой текст или составное содержимое из псевдоэлементов.

<a href="#more-info">Read more about Accessibility</a>

aria снимок

- link "Read more about Accessibility"

Текстовые поля​

Элементы ввода типа text показывают содержимое своего атрибута value.

<input type="text" value="Enter your name">

aria снимок

- textbox: Enter your name

Списки с элементами​

Упорядоченные и неупорядоченные списки включают свои элементы списка.

<ul aria-label="Main Features">
  <li>Feature 1</li>
  <li>Feature 2</li>
</ul>

aria снимок

- list "Main Features":
  - listitem: Feature 1
  - listitem: Feature 2

Группированные элементы​

Группы захватывают вложенные элементы, такие как элементы <details> с содержимым summary.

<details>
  <summary>Summary</summary>
  <p>Detail content here</p>
</details>

aria снимок

- group: Summary

Атрибуты и состояния​

Часто используемые ARIA атрибуты, такие как checked, disabled, expanded, level, pressed и selected, представляют состояния управления.

Флажок с атрибутом checked​

<input type="checkbox" checked>

aria снимок

- checkbox [checked]

Кнопка с атрибутом pressed​

<button aria-pressed="true">Toggle</button>

aria снимок

- button "Toggle" [pressed=true]