Browser context — bitta browser process ichida cookie, local storage, session storage, cache va permissionlari boshqa contextlardan ajratilgan mustaqil sessiya muhitidir. U incognito profilga o‘xshaydi, ammo automation framework tomonidan tez yaratilib, test tugaganda to‘liq yopiladi. Playwright va Puppeteer kabi vositalar test izolyatsiyasi uchun contextdan foydalanadi.
Izolyatsiya chegarasi
Bir contextdagi login cookie si boshqa contextga ko‘rinmaydi. IndexedDB, service worker va origin storage ham odatda context doirasida ajratiladi. Shu sabab ikki foydalanuvchili chat yoki access-control ssenariysini bitta browser processda ikki mustaqil context bilan tekshirish mumkin.
Context browser processdan yengilroq. Har test uchun butun browserni qayta ishga tushirish o‘rniga yangi context yaratish parallelism va tezlikni yaxshilaydi. Engine crashi yoki process darajasidagi flaglar esa bir browserdagi barcha contextga ta’sir qilishi mumkin.
Page va lifecycle
Context ichida bir yoki bir nechta page, popup va tab bo‘lishi mumkin. Popup parent page hodisasi orqali olinadi, lekin bir xil storage va permissionlarni ulashadi. Context yopilganda unga tegishli barcha pagelar, connectionlar va vaqtinchalik storage tugatiladi.
Test fixture contextni test boshida yaratib, yakunda failure bo‘lsa ham yopadi. Global contextni suite bo‘ylab ulashish test tartibiga bog‘liqlik keltiradi. Agar authentication state qayta ishlatilsa, u har testga yangi context yaratishda yuklanadi.
Sozlamalar
Viewport, locale, timezone, geolocation, color scheme, user agent va HTTP credential context darajasida belgilanishi mumkin. Permissionlar origin bo‘yicha beriladi. Device emulation viewport va touchni sozlaydi, lekin real qurilmaning CPU, GPU va browser buildini to‘liq takrorlamaydi.
Proxy ayrim frameworklarda browser launch, boshqalarida context darajasida bo‘lishi mumkin. Video, trace va download katalogi ham lifecyclega bog‘lanadi. Sozlama qaysi qatlamga tegishli ekanini bilmaslik parallel testlarda kutilmagan umumiy holat yaratadi.
Authentication state
Login jarayonidan keyin storage state faylga chiqarilib, keyingi contextlarga berilishi mumkin. Bu UI loginini har testda takrorlashni kamaytiradi. State tarkibida session token bo‘lishi sabab u secret sifatida saqlanadi, repositoryga qo‘shilmaydi va amal muddati nazorat qilinadi.
Har rol uchun alohida state ishlatiladi. Server-side session bekor qilingan bo‘lsa eski cookie fayli testni tiklamaydi. Test authenticationning o‘zini tekshirayotganida saved state ishlatilmaydi, aks holda muhim login oqimi chetlab o‘tiladi.
Network boshqaruvi
Context darajasidagi routing barcha pagelarning requestlarini kuzatishi, bloklashi yoki mock response qaytarishi mumkin. Bu third-party resursni izolyatsiya qiladi, ammo ortiqcha mocking real integratsiya nuqsonini yashiradi. Service worker requestni ushlab qolsa routingning ko‘rinishi framework va konfiguratsiyaga bog‘liq.
Context alohidaligi backend ma’lumotlarini avtomatik ajratmaydi. Ikki context bir xil account yoki database obyektidan foydalansa testlar baribir to‘qnashishi mumkin. UI storage izolyatsiyasi server-side test data strategiyasi bilan birga ishlaydi.
Ko‘p foydalanuvchili ssenariy
Ikki context bir browser processda buyer va seller kabi alohida rollarni ifodalaydi. Birinchi context amal yaratadi, ikkinchisi notification yoki yangilangan holatni kutadi. Test har action qaysi context va page orqali bajarilganini aniq saqlaydi. Shared backend hodisasi asinxron bo‘lsa UI assertion retry bilan sinxronlanadi.
Contextlar orasida clipboard, download katalogi yoki OS dialogi kabi process va tizim darajasidagi resurslar to‘liq ajralmasligi mumkin. Parallel test bunday imkoniyatdan foydalansa alohida browser process yoki worker isolation talab qilinadi.
Bog‘liq tushunchalar
Browser automation, Cookie, Session storage, Incognito mode, Page, Authentication state, Test isolation