Наскрізне тестування розширень Chrome з Playwright

Коротка відповідь

Запускайте Chromium із комплекту Playwright у persistent context і завантажуйте зібрану папку. Використовуйте документований канал chromium для headless із розширеннями або видимий режим. Поточна документація зазначає, що Google Chrome й Microsoft Edge прибрали потрібні цьому налаштуванню прапорці завантаження розширень.

Перевіряйте видимий результат у встановленому пакеті: параметр переживає відкриття, результат впровадження з’являється на тестовій сторінці або експорт має потрібний вміст. Пряме відкриття popup.html перевіряє сторінку, але не відтворює кнопку браузера й не надає автоматично activeTab.

Практичні кроки реалізації

1. Спершу зберіть пакет і вкажіть корінь із manifest.json. Перевірка коду з іншим завантажуваним каталогом пропускає помилки пакування. Зафіксуйте Playwright і встановіть відповідний браузер у CI.
2. Для незалежних тестів використовуйте новий тимчасовий профіль. Діліть його лише для явного перезапуску чи оновлення; паралельні процеси не мають змагатися за одну папку.
3. Для розширення з воркером отримайте ID із його URL. Не зашивайте локальний ID розробника. Без воркера потрібна інша ідентифікація.
4. Перевіряйте видимі результати locators із повторенням. Очікуйте підтвердження запису замість довільної паузи. Закрийте й відкрийте сторінку для перевірки збереження.
5. Додайте контрольовану локальну HTTP-сторінку для контентних скриптів. Окремо перевірте навігацію, відмову, повторний виклик і відновлення. Не включайте сторонні живі сайти в детерміновані CI-перевірки.

Процес звіту на зразок LocaleStress потребує тестів пропущених вузлів, конфліктів відновлення та історії; один параметр їх не доводить. Окремо називайте перевірки кнопки браузера й встановлення Store у доказах випуску.

Приклад реалізації

Приклад очікує MV3-воркер і вікно з checkbox Highlights, кнопкою Save та підтвердженням #status. Пристосуйте селектори до продукту. Код не запускався проти пакета розширення портфоліо.

import { test, expect, chromium } from "@playwright/test";
import path from "node:path";

test("saved preference survives reopening", async () => {
  const extensionPath = path.resolve("dist");
  const context = await chromium.launchPersistentContext("", {
    channel: "chromium",
    args: [
      `--disable-extensions-except=${extensionPath}`,
      `--load-extension=${extensionPath}`,
    ],
  });
  try {
    const worker = context.serviceWorkers()[0]
      ?? await context.waitForEvent("serviceworker");
    const id = new URL(worker.url()).host;
    let page = await context.newPage();
    await page.goto(`chrome-extension://${id}/popup.html`);
    await page.getByLabel("Highlights").uncheck();
    await page.getByRole("button", { name: "Save", exact: true }).click();
    await expect(page.locator("#status")).toHaveText("Saved.");
    await page.close();
    page = await context.newPage();
    await page.goto(`chrome-extension://${id}/popup.html`);
    await expect(page.getByLabel("Highlights")).not.toBeChecked();
  } finally {
    await context.close();
  }
});

Компроміси та альтернативи

Headless Chromium корисний для CI; видимий перегляд — для справжньої кнопки й бічної панелі. Traces і знімки пояснюють відмови, але можуть містити дані сторінки. Використовуйте контрольовані приклади й свідомо зберігайте артефакти. Модульні тести дешевші для перетворення звітів і перевірок.

Поширені помилки

• Використовувати звичайний непостійний контекст для розширення.
• Вважати кожен канал Chrome сумісним із прапорцями.
• Вважати пряме відкриття вікна жестом activeTab.
• Ділити один профіль між паралельними тестами.
• Робити паузу замість очікування видимого завершення.

Контрольний список випуску

• ☐ Перевіряється каталог пакета.
• ☐ Профілі й тестові сторінки ізольовані.
• ☐ Перевірки очікують видимі результати.
• ☐ Дозволи кнопки й заборонені сторінки мають окреме покриття.
• ☐ CI записує версії та корисні артефакти відмов.

Поширені запитання

Чи знімок доводить роботу розширення?

Він доводить стан відображення, а не збереження, дозволи чи відновлення. Додайте поведінкові перевірки.

Чи кожен тест має завантажувати розширення?

Ні. Чисті рішення перевіряйте модульно, браузер залиште реальним межам.

Що автоматизувати спочатку?

Один головний результат і одну відмову у зібраному пакеті з явним записом про ручну перевірку кнопки, якщо вона ще потрібна.

Первинні джерела

• Розширення Chrome у Playwright
• Перевірки Playwright
• Виклик користувачем activeTab

Пов’язані посібники та приклади

• Тематичний розділ
• Модульне тестування логіки розширень Chrome
• Як створити розширення Chrome з Manifest V3
• Структура проєкту розширення Chrome, що масштабується
• Збережені параметри й процес звітів LocaleStress