IHOR.DEVБАЗА_ЗНАНЬ
МЕНЮ

~/blog / Публікація / unit-testing-chrome-extension-logic.md

// посібник · 3 хв читання

Модульне тестування логіки розширень Chrome

Перевіряйте чисті рішення розширення через Node test runner, обмежуйте браузерні імітації та відрізняйте тести зберігання від інтеграції Chrome.

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

Модульно перевіряйте рішення зі звичайними значеннями й результатами: зберігання, валідацію, форматування, міграцію та фільтрацію. Залиште chrome-виклики у вузькому адаптері, щоб базова логіка не потребувала фальшивого браузера. Імітація сховища доводить запит запису, але не квоту Chrome, дозволи чи життєвий цикл.

Приклад використовує політику збереження звітів. LocaleStress описує необов’язкову історію до 20 звітів у бюджеті 3 MB. Код демонструє лише правило кількості, не є реалізацією продукту й не забезпечує байтовий бюджет.

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

  1. Винесіть політику зі слухача. Обробник читає дані, викликає чисте рішення та застосовує результат. Імпорт модуля рішення не має реєструвати браузерні події як побічний ефект.
  2. Пишіть приклади за вимогами: порожня історія, менше межі, рівно межа, перевищення й неправильні межі. Вкажіть порядок введення; функція не може вгадати місце найновішого елемента.
  3. Перевіряйте незмінність, якщо виклики на неї покладаються. Сортування чи обрізання на місці може змінити список UI та зробити наступні операції несподіваними.
  4. Окремо перевіряйте адаптери вузькою імітацією, яка записує виклики та може відмовляти. Покрийте відмови читання й запису замість складного фальшивого Chrome.
  5. Залиште браузерній інтеграції справжні дозволи, повідомлення, перезавантаження й точки входу пакета. Зробіть модульний набір швидким для звичайних змін.

Тест має падати після порушення важливого правила. Копіювання точного виразу реалізації в очікуваний результат повторює ту саму помилку. Використовуйте конкретні записи й граничні випадки з політики.

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

Збережіть політику як retention.mjs. Вона очікує спершу найновіші записи й повертає новий масив.

export function retainRecent(records, limit = 20) {
  if (!Number.isInteger(limit) || limit < 0) {
    throw new RangeError("limit must be a non-negative integer");
  }
  return records.slice(0, limit);
}

Збережіть тест як retention.test.mjs і виконайте node --test retention.test.mjs.

import test from "node:test";
import assert from "node:assert/strict";
import { retainRecent } from "./retention.mjs";

test("keeps newest records without mutating input", () => {
  const input = [{ id: "new" }, { id: "old" }];
  assert.deepEqual(retainRecent(input, 1), [{ id: "new" }]);
  assert.deepEqual(input, [{ id: "new" }, { id: "old" }]);
});

test("handles empty, zero, and invalid limits", () => {
  assert.deepEqual(retainRecent([], 20), []);
  assert.deepEqual(retainRecent([{ id: "new" }], 0), []);
  assert.throws(() => retainRecent([], -1), RangeError);
});

Байтовий бюджет потребує додаткових прикладів із фактичним серіалізованим розміром, визначеною одиницею та правилом для одного завеликого звіту. Тести кількості не доводять бюджет сховища.

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

Вбудованого Node runner достатньо для малих чистих модулів. Засіб фреймворку може краще інтегруватися з наявним TypeScript-збиранням і UI-тестами. Виберіть узгоджений інструментарій; зміна runner не виправить рішення, пов’язане з глобальними об’єктами браузера.

Property-based тести досліджують багато послідовностей після визначення політики. Конкретні приклади залишаються корисними для пояснення порядку й відмов майбутньому розробнику.

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

  • Називати фальшивий chrome браузерним інтеграційним тестом.
  • Перевіряти лише успішний запис без відмови.
  • Створювати очікування тим самим алгоритмом, що реалізація.
  • Називати обмеження кількості доказом байтів чи шифрування.

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

  • Чисті модулі імпортуються без браузерних глобальних об’єктів.
  • Граничні випадки відповідають вимогам.
  • Адаптери перевіряють відмови й потрібні виклики.
  • Браузерні твердження мають інтеграційні докази.
  • Команди тестування й середовище задокументовані.

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

Чи потрібен пакет імітації Chrome API?

Лише якщо суттєво спрощує адаптерні тести. Вузький переданий інтерфейс доречніший для двох методів.

Чи доводять модульні тести міграцію при оновленні?

Вони доводять перетворення даних. Реальне оновлення потребує старого встановленого стану й нового пакета.

З чого починати?

Виберіть найважливіше чисте правило й приклади відмов. Потім додайте браузерний тест інтеграції, яку модульний тест свідомо не спостерігає.

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

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

Ігор Харчишин

Незалежний full-stack інженер продуктів, який пише посібники з реалізації розширень браузера та сучасних вебпродуктів на основі першоджерел.

Потрібно реалізувати це у вашому продукті?

Перегляньте відповідні приклади продуктів або поділіться контекстом розробки вебзастосунку, розширення Chrome, API чи SaaS.