Зачем при тестировании очищать кэш
Что проверяют
Знаете ли вы, какие кэши стоят между пользователем и кодом, и понимаете ли, когда очистка помогает тестированию, а когда прячет баг. Следом часто спрашивают: «после очистки кэша всё работает, закрываем баг?»
Как отвечать
Кэш очищают, чтобы проверять именно ту сборку и то состояние, которые задуманы:
- новая версия после выкладки: браузер может держать старые JS и CSS, и вы проверяете вчерашний фронтенд с сегодняшним бэкендом;
- первый визит: сценарий нового пользователя, холодная загрузка, пустые
localStorage, cookie и IndexedDB; - изоляция автотестов: состояние от предыдущего теста не должно влиять на следующий. В Playwright каждый тест по умолчанию получает свежий
BrowserContext, в Selenium это нужно обеспечить самому; - замеры скорости: холодный и тёплый кэш дают разные цифры, мерить нужно оба варианта осознанно.
Инструменты: галочка Disable cache на вкладке Network в DevTools (работает, пока DevTools открыты), жёсткая перезагрузка, Application → Clear site data, отдельный профиль или инкогнито. На Android очистка данных приложения в настройках или adb shell pm clear <package>. Service Worker держит свой кэш отдельно от HTTP-кэша, про него забывают чаще всего.
Помните и про слои дальше браузера: CDN, серверный кэш вроде Redis, кэш в API-шлюзе. Старые данные иногда приходят оттуда.
Бывает, что кэш нужно не чистить, а тестировать: правильные ли заголовки Cache-Control и ETag, получает ли пользователь с кэшем новую версию после релиза, есть ли хэш в именах файлов бандла.
Где спотыкаются
Используют очистку как ритуал и закрывают баг со словами «у меня после очистки работает». Реальные пользователи кэш не чистят, так что это, скорее всего, дефект инвалидации, и его нужно завести.
Путают слои: чистят браузер, а старый ответ отдаёт CDN или серверный кэш. Потом полдня ищут в коде баг, которого там нет.
В автотестах ради скорости переиспользуют профиль браузера между тестами. Тесты начинают зависеть от порядка запуска и падают нестабильно.