Фикстуры и изоляция браузерной автоматизации
Проектируйте фикстуры с ясным владельцем, изолированным состоянием, безопасными параллельными worker и детерминированной очисткой.
Нужна структурированная документация по теме Начало работы?
Эта статья относится к редакционной библиотеке. Для пошаговой настройки, справки и постоянных обновлений переходите сразу в соответствующий раздел docs.
Надёжная браузерная автоматизация начинается с фикстуры, которой принадлежат небольшой и явно объявленный набор ресурсов. Она может создать контекст, страницу, временный каталог и синтетические данные приложения. Также нужно указать, кто закрывает каждый ресурс и какой результат сохраняется при ошибке проверки.
Главное правило таково: тест получает известные входы, наблюдает ограниченный результат и освобождает созданные ресурсы. Playwright описывает эту модель в документации о тестовых фикстурах, а Selenium объясняет независимые тесты в практиках тестирования. Для границ контекста полезно свериться с руководством по жизненному циклу Playwright.
Сначала опишите контракт фикстуры
Контракт называет входы, выходы и владельца. Входами могут быть версия браузера, параметры контекста, разрешённая синтетическая учётная запись, подготовленная запись и каталог worker. Выходы должны быть краткими: категория результата, видимая проверка и квитанция очистки. Удаление удалённой записи остаётся обязанностью приложения.
Размещайте настройку рядом с нужной областью действия. Контекст на тест подходит, когда каждому случаю нужен чистый старт. Браузер на worker допустим, если каждый worker создаёт свой контекст и файлы. Общая страница может сохранять cookies, воркер службы и память дольше нужного. Область следует отражать в имени фикстуры.
Разделяйте владельца браузера и владельца приложения. Фикстура может открыть страницу и выполнить разрешённый вход, но приложение определяет выход из сессии, а сервис определяет хранение записи. Закрытие контекста освобождает состояние браузера, но не отзывает сессию на другом устройстве и не отменяет удалённую мутацию.
Записывайте метку сценария, версию, область, метку синтетического входа и результат очистки. Не помещайте cookies, токены, полные ответы или личный текст страницы в обычные журналы. Для понимания результата не должна требоваться копия всей сессии.
Выберите область без случайного общего состояния
Процесс, браузер, контекст, страница, worker и тест имеют разные области. Браузер содержит несколько контекстов, контекст группирует страницы и хранилище, страница представляет вкладку. Передавайте контекст или страницу в helper явно, а не ищите глобальную страницу.
Создавайте новый контекст, если важны cookies, хранилище, разрешения, воркер службы или чистое состояние origin. Изоляция предотвращает смешивание состояния браузера, но не является песочницей операционной системы. Приложение всё ещё пишет в общие сервисы, а runner может делить файлы. Для каждого внешнего ресурса нужен владелец.
Снимок storageState является входом с жизненным циклом, а не универсальной резервной копией. В нём могут быть cookies и хранилище origin, но не память, очереди worker, нативные учётные данные и не вся серверная сессия. Считайте его чувствительным синтетическим артефактом. Копируйте основу только для чтения в путь worker и помечайте неполный файл недействительным.
Та же граница действует для профилей Selenium. Каталог профиля, driver и бинарный файл образуют один вход совместимости. Дайте каждой сессии собственный путь и закрывайте driver штатным способом. Руководство по интеграции профиля Selenium раскрывает эту модель. Профиль воспроизводит объявленные входы, но не решение сервиса.
Подготовьте состояние для параллельных worker
Параллельные worker ломаются, когда делят файл состояния, каталог загрузки, синтетическую учётную запись или имя снимка. Файл может быть корректным, но принадлежать другому worker. Назначьте каждому worker метку сценария и закрытый каталог под утверждённым корнем артефактов.
Загружайте основу только для чтения и записывайте новое состояние рядом. Фикстура входа может обновить синтетическую сессию и сохранить её с worker и номером попытки. Частичный результат изолируйте или пометьте недействительным. Не заменяйте основу, пока другой контекст может её читать.
Чистый браузер не устраняет гонку в сервисе. Используйте независимые синтетические записи, документированный сброс или сценарий только для чтения. Если мутацию нужно разделить, выполняйте именно эту операцию последовательно и укажите владельца. Случайная задержка не решает гонку.
Наблюдения каждого worker должны быть ограничены. Достаточно категории URL, видимого статуса и короткого имени ошибки. Разрешённый trace или снимок записывайте в путь конкретного worker с обычным сроком хранения. Файл с правильным именем, но данными другого worker, означает сбой фикстуры.
Сделайте очистку детерминированной
Очистка является частью корректности. Размещайте её в finally после успеха, проверки, тайм-аута или ошибки настройки. Закрывайте страницы с коротким сроком, затем контекст, которому они принадлежат. Владелец общего браузера закрывает его после всех контекстов; контракт запуска решает, должен ли другой компонент только отключиться.
Сохраняйте первую ошибку, если очистка тоже завершается ошибкой. Запишите ошибку сценария, выполните закрытие и добавьте ошибку очистки. Замена исходной проверки ошибкой закрытия скрывает причину. Игнорирование закрытия оставляет открытую сессию при внешне успешном результате.
Закрывайте загрузки, записи, дескрипторы и временные каталоги, созданные тестом, через их API. Закрытие контекста не удаляет файл, уже переданный в хранилище артефактов, и не отменяет мутацию, отправленную серверу. Если контракт приложения требует выхода, выполните его до закрытия страницы.
Очистка должна выдерживать повторный вызов. Тайм-аут может оставить частично созданную страницу, а runner может вызвать защитный hook после фикстуры. Проверьте handle и закрывайте его, только пока фикстура владеет ресурсом. Не закрывайте другой контекст из-за похожего имени.
Согласуйте повторы и свидетельства
Повтор является новым запуском, а не продолжением неизвестной страницы. Сначала решите, была ли операция только чтением и предоставляет ли приложение проверку идемпотентности или статуса. При разрешённом повторе закройте старый контекст, создайте новый с теми же синтетическими входами и запишите номер попытки. Поздний успех не доказывает безопасность первой попытки.
Разделяйте ошибки настройки, приложения, проверки и инфраструктуры. Отсутствующий файл относится к фикстуре, отклонённый запрос к приложению или сервису, отключение driver к инфраструктуре. Тайм-аут на заголовок называет отсутствующий сигнал, но не объясняет решение сервиса.
Диагностика должна называть условие, а не копировать сессию. Включите сценарий, версии, категорию URL, ожидаемый ориентир и состояние очистки. Снимок синтетической страницы может помочь, но способен содержать секреты. Ограничьте доступ и срок; позднее удаление не возвращает уже распространённую копию.
Проверьте путь ошибки на синтетической странице, которая не выдаёт один сигнал готовности. Ожидаемый результат это ограниченная ошибка с названием сигнала и квитанция очистки. Не нужно обращаться к несвязанным origin или расширять сбор данных ради успеха.
Проверьте границу приложения
Изоляция браузера даёт известную клиентскую отправную точку. Она не гарантирует независимость серверных сессий, принятие cookie или очистку приложения. Проверяйте наблюдаемую границу: в новом контексте нет ожидаемого локального состояния, защищённый маршрут следует контракту, следующая заявка имеет ожидаемый результат.
Смену учётной записи проверяйте как переход состояния. Используйте предусмотренный выход, удаляйте только документированное клиентское состояние и создавайте следующий контекст с отдельным одобренным состоянием. Проверяйте видимый заголовок или результат доступа. Другая вкладка, worker, offline-очередь или воркер службы могут сохранить старый экран.
Держите фикстуру вдали от поиска аккаунтов и сбора частных сигналов. Разрешённому тесту нужны известная учётная запись, объявленный маршрут и наблюдаемый результат. При недоступной зависимости запишите категорию и остановитесь на разрешённой границе.
После обновления браузера или приложения повторите чистый контекст, загрузку и истечение состояния, смену аккаунта, работу worker, параллельные файлы и закрытие после ошибки. Сравнивайте видимый результат и сохраняйте версии среды.
Возможности и ограничения BotBrowser
BotBrowser предоставляет изолированные BrowserContexts с отдельными cookies, хранилищем и состоянием сессии. Это позволяет разрешённой фикстуре повторять синтетический сценарий и проверять, что новый контекст не наследует локальное состояние. Документация BotBrowser об изоляции нескольких аккаунтов описывает эту границу браузера. BotBrowser не заменяет управление жизненным циклом Playwright или Selenium, очистку приложения, отзыв серверной сессии и работу с секретами. Он не гарантирует принятие просроченной cookie, не удаляет очередь воркера службы и не стирает запись провайдера. Эти обязанности остаются у владельца фикстуры и приложения.
Используйте возможность как объявленный вход, а не как удалённый результат. Записывайте версию, назначение контекста, источник состояния, метку worker, ожидаемую очистку и наблюдение. Ограничение должно быть рядом, чтобы чистый локальный контекст не выглядел доказательством удалённого удаления.
Практическая проверка спрашивает, владеет ли каждый тест изменяемым состоянием, может ли worker перезаписать чужой файл, достигает ли каждый сбой одной очистки и указано ли, что не наблюдалось. Так фикстура остаётся обслуживаемой при смене браузера или framework.
Если тест использует подготовленный ответ сервиса, сохраняйте владение входами и выходами. Симулятор принадлежит сценарию, использует синтетические данные и сбрасывает состояние вместе с контекстом. Подготовленный ответ не доказывает поведение настоящего сервиса.
У каталога артефактов также есть владелец. Worker записывает результат, но CI решает, кто его читает и когда он истекает. Отделяйте краткую квитанцию от более чувствительного снимка или trace, чтобы проверка не открывала лишнее.
Исправление фикстуры должно менять причину, а не только симптом. Если два случая ошибочно делят запись, разделите их или опишите совместную операцию. Если очистка не удалась, сохраните ошибку и передайте её владельцу runner.
Описание сценария должно соответствовать коду. Повторяйте проверку области после смены браузера, framework, схемы состояния или сервиса. Короткий актуальный контракт не позволит будущей фикстуре использовать временный путь как общий ресурс.
Перед слиянием изменения запустите случай с чистым контекстом, случай с истёкшим состоянием и случай с принудительной ошибкой очистки, используя один формат квитанции. Сравните метку worker, область ресурса, видимую проверку и итог очистки.
Сохраняйте синтетические входы и публикуйте только краткую квитанцию. Если поведение сервера отличается, передайте владельцу приложения идентификатор запроса; закрытие контекста не доказывает удаление записи на сервере.
BotBrowser поддерживает согласованную конфигурацию браузера для каждого тестового контекста; BotBrowser не удаляет данные, которые приложение хранит в собственных сервисах.
Источники
Похожие статьи
Переведите BotBrowser из исследований в продакшн
Используйте эти руководства, чтобы понять модель, а затем перейти к кроссплатформенной валидации, изолированным контекстам и масштабируемому браузерному развертыванию.