Web Platform Tests для уверенности в возможностях браузера

Web Platform Tests дают доказательство соответствия заявленным условиям, но не гарантируют каждый путь приложения. Разделяйте спецификацию, общий тест, локальную проверку и видимый сигнал приложения. Возможность не раскрывает личность или устройство. BotBrowser может предоставить контролируемый профиль для запуска проверок возможностей, но не может изменить то, как стандарт определяет возможность или как её реализует другой браузер.

Кратко

• Проходящий тест WPT доказывает один алгоритм в объявленных условиях origin, harness и момента запуска, но не то, что пользовательский сценарий завершится.
• Сначала читайте метаданные: пометка tentative, flaky или ожидаемого падения это вопрос об охвате, а тест, пропущенный из-за небезопасного origin или отсутствия жеста пользователя, не становится зелёной ячейкой.
• Держите раздельно пять состояний, missing, available, denied, failed и completed: присутствующий метод ничего не говорит о выданном разрешении или о записи на сервере.
• Доказывайте прикладную половину отдельно: ответ 201 с заголовком Location, объявление внутри элемента с role="status" и aria-live="polite", и запасная кнопка, доступная с клавиатуры.
• Храните в одной записи путь WPT, раздел спецификации, сборку браузера, версию harness, ревизию fixture и дату результата, и повторяйте подмножество при изменении любого из них.

Содержание

• Выбор доказательства WPT
• Проверка возможности
• Таблица решения
• Сбойный fixture
• Проверка приложения
• BotBrowser: границы
• Практический итог

Выбор доказательства WPT

Изучите репозиторий WPT и API testharness. Запишите путь, спецификацию, версию, origin, разрешения и дату. Пропущенный, экспериментальный или ожидаемо неудачный тест требует резервного пути. Об экспериментальных функциях и их доступности см. Origin Trials и экспериментальные функции Web Platform.

Читайте метаданные вместе с результатом. Локальный запуск может отличаться из-за защищённого контекста, жеста пользователя или политики разрешений. Перед повторным использованием проверьте лицензию, зависимости и очистку.

Воспроизводимое наблюдение за harness

Открытая реализация WPT позволяет проверить границу harness. В закреплённой копии выполните git grep -n "promise_test" -- resources | head -5, затем откройте resources/testharness.js в репозитории WPT. Совпадения показывают, что возвращённый Promise завершается внутри harness, а test.done() или его callback закрывает тест. Это отличается от ответа сервера продукта. Такое наблюдение отделяет успешный тест WPT, доказывающий достижение assertion браузером, от записи, сохранённой приложением. Храните commit и путь теста рядом с результатом, чтобы другой проверяющий мог повторить осмотр. Записывайте подтверждение сервера как отдельную assertion приложения в журнале.

Проверка возможности

Проверяйте нужный метод непосредственно перед вызовом. Разделяйте отсутствует, доступен, запрещён, завершился ошибкой и завершён. Наличие свойства не доказывает разрешение, доступность сервиса или запись на сервере. Данные совместимости и запасные пути для отсутствующих API рассмотрены в материале Данные совместимости Browser API и резервные пути.

Сохраняйте ввод и предлагайте доступный резервный путь. Записывайте origin, контекст, версию, состояние, резервный путь и видимый результат без лишних данных.

Таблица решения

Наблюдение	Решение	Видимый результат	Граница
WPT прошёл в матрице	включить кандидат	попробовать после проверки	заявленное соответствие
WPT пропущен или экспериментален	изучить метаданные	сохранить резервный путь	покрытие тестом
Метод отсутствует или контекст заблокирован	использовать резервный путь	сохранить задачу	возможность страницы
Вызов отклонён	классифицировать один раз	показать восстановление	поведение браузера
Вызов завершён	проверить приложение	подтвердить видимый сигнал	браузер и приложение

Сбойный fixture

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

async function run() {
  const h = document.createElement('div');
  h.innerHTML = '<p id="state"></p><button id="fallback" hidden>Использовать резервный путь</button>';
  document.body.append(h);
  const state = h.querySelector('#state');
  const fallback = h.querySelector('#fallback');
  try {
    const ok = typeof navigator.share === 'function';
    const result = ok
      ? await navigator
          .share({ title: 'Синтетический элемент', url: '/fixture' })
          .then(() => 'done')
          .catch(() => 'failed')
      : 'missing';
    state.textContent = result === 'done' ? 'Завершено' : 'Используйте резервный путь';
    if (result !== 'done') fallback.hidden = false;
    console.assert(state.textContent && (result === 'done' || !fallback.hidden));
    return result;
  } finally {
    h.remove();
  }
}

Проверка приложения

После вызова проверьте сообщение, элемент или запись, принадлежащие приложению. Успешная promise не доказывает запись на сервере. Разделяйте результаты и проверяйте фокус, клавиатуру, подписи и восстановление.

Повторяйте матрицу после версии, спецификации, защищённого контекста, разрешения или изменения harness. Сохраняйте путь WPT, состояние, резервный путь и дату без личного содержимого. Как организовать такую матрицу по платформам и выпускам, описано в материале Матрица браузерных тестов по платформе и release.

BotBrowser: границы

BotBrowser предоставляет контролируемые контексты для разрешённых сценариев по мотивам WPT и повторяемых проверок. Изолированный контекст разделяет изменяемое состояние и сравнивает видимые результаты.

Он не сертифицирует WPT, не выдаёт разрешения, не делает origin безопасным, не заменяет инфраструктуру соответствия и не доказывает серверную транзакцию. Документация об изоляции BotBrowser подтверждает повторяемость, а не универсальную гарантию.

Смотрите также руководство по совместимости API и руководство WebDriver BiDi.

BotBrowser предоставляет повторяемые проверки в разрешённых контекстах по мотивам WPT, но не гарантирует соответствие, не выдаёт разрешения и не заменяет доказательство транзакции. Записывайте обе границы.

Уверенность выше, когда у спецификации, WPT, матрицы браузеров, приложения и fixture есть ответственный. Сохраняйте путь, версию, origin, состояние, резервный путь и видимый результат.

Используйте отрицательные результаты честно. Пропуск, отказ или тайм-аут нужно классифицировать, а резервный путь удалять только после подтверждения приложения.

Сохраняйте краткую запись с путём WPT, версией, контекстом, состоянием и видимым утверждением.

Сравнивайте кандидат с предыдущей версией тем же fixture и сохраняйте первую существенную ошибку.

Указывайте ответственного и дату проверки для каждого исключения.

Называйте видимый резервный путь, чтобы поддержка повторила результат.

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

Так узкое доказательство не станет универсальным обещанием.

Записывайте дату и ответственного за следующую проверку.

Так уверенность остаётся актуальной.

Результат должен сохранять границу между соответствием и поведением приложения.

Не выдавайте контролируемый контекст за универсальную гарантию.

Источники

• Репозиторий Web Platform Tests
• API testharness WPT
• BotBrowser: изоляция

Практический итог

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

Сначала прогоните fixture на синтетической странице с подменённым navigator.share и скрытой кнопкой #fallback, сохранив вызовы console.assert, которые проверяют видимый текст и запасной путь вместе. Затем повторите тот же сценарий в контролируемом контексте, который сопровождает wpt run --channel dev --log-wptreport wptreport.json, чтобы сборка браузера стояла рядом со счётчиками pass, skip и fail вместо вручную перенесённой таблицы.

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