Регрессионное тестирование после обновления конфигурации

sw-precache — это инструмент для автоматической генерации сервис-воркеров, обеспечивающих кэширование ресурсов веб-приложения. Он позволяет заранее указать файлы, которые должны быть сохранены в кэше, и оптимизировать работу приложения в оффлайн-режиме. Основной механизм работы заключается в сканировании проекта, создании списка файлов для кэширования и генерации файла сервис-воркера с соответствующей логикой.

Файлы конфигурации sw-precache обычно задаются через объект с ключевыми параметрами:

{
  staticFileGlobs: ['dist/**.*'],
  stripPrefix: 'dist/',
  runtimeCaching: [{
    urlPattern: /\/api\/.*\//,
    handler: 'networkFirst'
  }]
}
  • staticFileGlobs — массив шаблонов файлов, которые будут добавлены в кэш.
  • stripPrefix — префикс пути, который нужно убрать при добавлении файлов в кэш, чтобы пути в кэше совпадали с путями на сервере.
  • runtimeCaching — массив правил динамического кэширования с указанием паттернов URL и стратегий кэширования.

Стратегии кэширования

sw-precache поддерживает несколько стратегий кэширования:

  1. cacheFirst — сначала проверяется кэш, если ресурс найден — возвращается он, иначе запрос идет на сеть.
  2. networkFirst — сначала делается запрос к сети, если ресурс недоступен — возвращается кэшированная версия.
  3. fastest — параллельно проверяются сеть и кэш, возвращается первый доступный ресурс.
  4. networkOnly / cacheOnly — ограничение доступа только к сети или только к кэшу.

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

Регрессионное тестирование после изменения конфигурации

После обновления конфигурации sw-precache необходимо убедиться, что сервис-воркер работает корректно, а кэшированные ресурсы соответствуют ожиданиям. Основные шаги регрессионного тестирования:

1. Проверка генерации сервис-воркера

При изменении staticFileGlobs или stripPrefix нужно проверить, что новый сервис-воркер содержит корректный список кэшируемых файлов. Это можно сделать, открыв сгенерированный service-worker.js и убедившись, что:

  • Все необходимые файлы присутствуют.
  • Путь к файлам соответствует новой структуре проекта.
  • Старые, больше не актуальные файлы удалены из кэша.

2. Проверка версионности кэша

sw-precache создает уникальный идентификатор кэша на основе хэшей файлов. При обновлении конфигурации важно убедиться, что новый сервис-воркер создает новый кэш, а старый — корректно удаляется.

self.addEventListener('activate', event => {
  const expectedCaches = ['my-app-cache-v2'];
  event.waitUntil(
    caches.keys().then(cacheNames => {
      return Promise.all(
        cacheNames.map(cacheName => {
          if (!expectedCaches.includes(cacheName)) {
            return caches.delete(cacheName);
          }
        })
      );
    })
  );
});

Проверка должна включать:

  • Актуальный список кэшей через caches.keys().
  • Удаление старых версий кэша после активации нового сервис-воркера.

3. Тестирование стратегий кэширования

Каждое правило из runtimeCaching должно быть протестировано:

  • Проверка networkFirst для API-запросов: отключение сети должно возвращать ранее кэшированные данные.
  • Проверка cacheFirst для статических ресурсов: изменения в файле должны обновлять кэш после перегенерации сервис-воркера.
  • Проверка fastest: одновременный доступ к сети и кэшу должен отдавать корректный результат.

4. Проверка оффлайн-режима

После обновления конфигурации необходимо:

  • Очистить кэш браузера.
  • Загрузить приложение оффлайн и убедиться, что все ресурсы подгружаются из кэша.
  • Проверить отсутствие ошибок в консоли сервис-воркера.

5. Интеграционное тестирование с CI/CD

Регрессионное тестирование должно быть автоматизировано, чтобы при каждом изменении конфигурации сервис-воркера:

  • Генерировался новый service-worker.js.
  • Выполнялись проверки наличия всех критически важных файлов в кэше.
  • Симулировался оффлайн-доступ к приложению и проверялось корректное поведение.

Пример автоматизированного теста с использованием Puppeteer:

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  await page.goto('http://localhost:8080');
  await page.setOfflineMode(true);

  const content = await page.content();
  console.assert(content.includes('main.js'), 'main.js должен быть загружен из кэша');

  await browser.close();
})();

6. Логирование и мониторинг ошибок

После обновления конфигурации стоит включить расширенное логирование при установке и активации сервис-воркера:

self.addEventListener('install', event => {
  console.log('Service worker installing...');
  event.waitUntil(self.skipWaiting());
});

self.addEventListener('activate', event => {
  console.log('Service worker activating...');
});

Логи помогают выявлять проблемы при регрессионном тестировании и отслеживать ошибки кэширования в реальном времени.

Особенности обновления конфигурации

  • Добавление новых правил runtimeCaching может потребовать увеличения версий кэша.
  • Изменение шаблонов в staticFileGlobs может привести к пропуску важных файлов, поэтому требуется тщательная проверка.
  • Удаление устаревших файлов из кэша должно быть явным, иначе сервис-воркер будет отдавать старый контент.

Регрессионное тестирование после обновления конфигурации sw-precache обеспечивает стабильность работы веб-приложения и предотвращает проблемы с устаревшими кэшами, неправильной загрузкой ресурсов и некорректным поведением в оффлайн-режиме.

Оглавление