Баги, которые действительно важны в offline-first, не сидят внутри отдельного экрана - они живут на границах. Граница это момент перехода: приложение уходит из online в offline, с одной версии на другую, из разрыва обратно в reconnect. На стабильном экране всё зелёное; ломается именно на стыке, когда меняется контекст, а код молча предполагает старый. Поэтому проверять надо переходы, а не наличие функций.

Естественная ошибка - поверить галочке. Lighthouse проверяет installability и что страницу контролирует воркер, это полезный аудит, но он не доказывает корректность offline-домена. Зелёный значок не скажет вам, что заметка, сохранённая офлайн, переживёт reload, что reconnect отправит outbox ровно один раз, а не дважды, и что при конфликте пользователь не потеряет свой текст. Аудит меряет форму, а нам нужна проверка поведения.

Отсюда список того, что реально надо бросить в приложение. Не happy path, а враждебная среда: медленная сеть, отказ DNS, timeout уже после того, как сервер закоммитил операцию, ответы 401, 409, 429, ошибка quota, вытеснение хранилища (eviction), повреждённые данные и закрытие вкладки между локальным commit и отправкой. Именно в этих состояниях наивный код теряет или дублирует данные, которых обычный клик мышью не воспроизводит.

Тестировать это надо на самом низком уровне, который ловит поведение. Юнит-тест для чистой логики дешевле и стабильнее e2e; e2e держат для немногих сквозных путей, которые нельзя проверить иначе. Разложение по уровням задаёт, что и где проверяется - от route matching в юнитах до manifest и иконок на реальных браузерах.