← Java

Після цього уроку ви зможете

Конспект і таймкоди

0:00

Тест має знати очікуваний стан

Після авторизації користувач може потрапити в різні компанії або проєкти й побачити різний контент. Це не означає, що один тест має приймати обидва варіанти через if: такий сценарій перестає однозначно повідомляти, яку бізнес-поведінку він перевірив.

Кожен тест повинен мати відомі передумови, послідовність дій і конкретний результат. «Універсальна» fixture корисна лише тоді, коли вона готує визначений стан, а не приховує невизначеність усередині сценарію.

0:58

Різні ролі означають різні функціональні тести

Free plan, trial та enterprise мають різні можливості: ліміти створення проєктів, доступні кнопки й повідомлення. Це окремі вимоги рольової моделі, тому їх варто перевіряти окремими тестами.

Наприклад, free-plan тест підтверджує відповідну позначку тарифу та обмеження створення проєкту, а enterprise-тест — доступність повного сценарію. Розгалуження між цими очікуваннями в одному тесті приховує дефект, якщо середовище випадково відкрило не ту роль.

2:08

Як знайти керівний стан у DevTools

Щоб зрозуміти, чому UI різниться, потрібно дивитися не лише на сторінку. У DevTools варто перевірити Network, cookies, localStorage і sessionStorage та знайти дані, які визначають активну компанію або роль.

У прикладі різницю задає companyId: конкретний ID відкриває корпоративний контекст, а відсутнє значення — free-проєкти. Це дає точну підказку, який стан треба підготувати перед тестом.

Термін

sessionStorage

Сховище, прив’язане до домену та вкладки. Playwright authentication guide окремо зазначає, що storage state не зберігає sessionStorage автоматично.

2:55

Окремі `storageState` і suites для кожного контексту

Fixture може завантажувати заздалегідь підготовлений Playwright storageState з потрібними cookies та companyId. Тоді free-plan і enterprise suites стартують одразу у своїх контрольованих контекстах і не залежать від випадкового вибору компанії.

Та сама модель працює не лише для тарифів: у медичному продукті це можуть бути doctor і patient, а всередині ролі — додаткові рівні доступу. Спільний end-to-end сценарій між ролями залишається окремим тестом, бо має іншу бізнес-мету.

Що змінилося після запису

storageState охоплює більше, ніж cookies і localStorage

У відеоУ відео сценарій побудований навколо cookies, storage state та companyId для вибору ролі.

АктуальноАктуальний API також уміє включати IndexedDB через indexed_db (додано у v1.51) і virtual WebAuthn credentials через credentials (додано у v1.61).

Перевірено 2026-07-31

Уточнення

Authentication state є секретом

State-файл може містити cookies і headers, достатні для impersonation. Офіційний guide радить зберігати його поза Git навіть у private repository.

Термін

BrowserContext

Ізольоване браузерне середовище Playwright. Окремі contexts не ділять cookies та інший стан, що підтримує відтворюваність тестів.

Термін

storageState

Знімок стану BrowserContext, який охоплює cookies, localStorage та, за явними options актуального API, IndexedDB або virtual WebAuthn credentials.

Приклад коду

Окремий context для Free-користувача

from pathlib import Path

import pytest
from playwright.sync_api import Browser


@pytest.fixture
def free_context(browser: Browser):
    context = browser.new_context(
        storage_state=Path("playwright/.auth/free.json")
    )
    yield context
    context.close()

Fixture створює isolated BrowserContext із наперед підготовленим Free-state; Enterprise-state має бути окремою fixture або parameterized input із чіткою очікуваною роллю.

Очікуваний результат: Тест стартує у визначеному Free-контексті без умовного розгалуження за випадковим UI-станом.

Потрібно: pytest, playwright

Практика

Розділити рольовий сценарій

  1. Візьми тест, який допускає Free або Enterprise через if, і розділи його на дві fixtures та два тести з однозначними assertions.
  • Кожен тест має одну відому роль до першої UI-дії.
  • У test body немає гілки, що вибирає очікування за фактичним тарифом.
  • State-файли не містяться в Git.
5:45

Як здавати практичні роботи

Практику можна здавати після кожного відео або однією завершеною роботою після комплексного рефакторингу модуля. Мінімальна мета — самостійно повторити показаний сценарій; корисніше додати невелике власне розширення, яке підтверджує розуміння.

Можна також принести приклад із реального проєкту, навіть іншою мовою програмування. Важливий не формат здачі, а виконана практика та можливість отримати предметний зворотний зв’язок.

Джерела та додаткові матеріали