Przejście na Manifest V3 to największy zwrot w ekosystemie Chrome od lat. Dla deweloperów i testerów oznacza nową architekturę, inne cykle życia rozszerzeń i świeże wyzwania w testowaniu automatycznym.
Co się zmieniło
W miejsce dawnych background pages (działających cały czas w tle) pojawiły się service workery – lekkie skrypty, które:
- startują w odpowiedzi na konkretne zdarzenia (np. kliknięcie w ikonę),
- po skończeniu pracy zostają uśpione przez przeglądarkę.
To wymusza nowy sposób myślenia o stanie rozszerzenia, przechowywaniu danych (chrome.storage zamiast localStorage) i planowaniu zadań (chrome.alarms zamiast setInterval).
Dlaczego testowanie stało się trudniejsze
1. Niedeterministyczny cykl życia
Service worker może się uruchomić, wykonać zadanie i zasnąć – lub zostać ubity w połowie operacji. Klasyczne założenie „kod działa od początku do końca" przestaje działać. Trzeba testować różne ścieżki: udany sukces, przerwanie w połowie, restart z przywróceniem stanu.
2. Asynchroniczność na każdym kroku
chrome.storage, chrome.alarms, komunikacja między skryptami – wszystko asynchroniczne. W testach trzeba obsłużyć Promise'y, async/await i race conditions, które w środowisku synchronicznym nie występowały.
3. Brak pełnych API w testach jednostkowych
Chrome APIs nie istnieją w środowisku Node.js. Trzeba mockować całe chrome.*, a to nie zawsze dokładnie odzwierciedla rzeczywiste zachowanie przeglądarki (np. limity chrome.alarms czy zachowanie chrome.storage pod obciążeniem).
Jakie testy pisać
Testy jednostkowe z mockami
Sprawdzają logikę biznesową w izolacji. Mocki chrome.storage, chrome.alarms pozwalają szybko weryfikować, czy kod reaguje poprawnie na różne dane wejściowe. Nie zastąpią prawdziwego środowiska, ale wyłapują błędy logiczne na wczesnym etapie.
Testy integracyjne / E2E
Tutaj odpalasz rozszerzenie w prawdziwej przeglądarce (np. przez Puppeteer lub Playwright), symulując interakcje użytkownika: kliknięcia w ikonę, otwieranie zakładek, czekanie na alarmy. To pozwala zobaczyć, jak service worker radzi sobie z prawdziwym lifecycle'em.
Testy "suspension & resume"
Kluczowe dla MV3. Napisz test, który:
- Uruchamia service worker,
- Zapisuje stan do chrome.storage,
- Symuluje zabicie workera (chrome.runtime.reload() lub ręczne wyłączenie),
- Ponownie budzi workera,
- Sprawdza, czy stan został odtworzony poprawnie.
Narzędzia, które pomogą
- Puppeteer / Playwright – uruchamianie Chrome z załadowanym rozszerzeniem, automatyzacja kliknięć i sprawdzanie wyników.
- sinon-chrome – gotowe mocki chrome.* API do testów jednostkowych.
- Chrome DevTools (Service Worker inspector) – podgląd na żywo: kiedy worker się budzi, kiedy zasypia, jakie alarmy są aktywne.
- Vitest / Jest – standardowe frameworki do testów jednostkowych, z możliwością mockowania modułów.
Najczęstsze pułapki
- Założenie ciągłego działania: Kod nie może zakładać, że worker działa non-stop. Zawsze projektuj z myślą o możliwym zatrzymaniu.
- Synchroniczne operacje storage: chrome.storage jest asynchroniczny – nie da się go użyć jak zmiennej globalnej.
- Zbyt częste alarmy: chrome.alarms ma minimum 1 minuty. Jeśli potrzebujesz częstszego wykonania, musisz znaleźć inne rozwiązanie (np. sprawdzanie w momencie wznowienia).
Podsumowanie
Manifest V3 to nowa era – wymusza asynchroniczność, planowanie z myślą o uśpieniu, testowanie lifecycle'u service workera. Kluczem do sukcesu jest:
- Pisanie testów jednostkowych z mockami (szybkie feedback),
- Pisanie testów E2E w prawdziwej przeglądarce (weryfikacja rzeczywistego zachowania),
- Testowanie „suspension & resume" (najbardziej podstępny scenariusz),
- Monitorowanie rozszerzenia w produkcji (bo prawdziwe zachowanie użytkowników potrafi zaskoczyć).
Jeśli chcesz dowiedzieć się więcej o naszym doświadczeniu z migracją do MV3, przeczytaj artykuł na oficjalnym blogu Chrome Developers: eyeo's journey to testing Manifest V3 service worker suspension
