Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Створіть BasePage з wait-aware click() і type_text().
Збережіть локатори login page як tuple (By.CSS_SELECTOR, value).
Створіть предметний login() і перевірку success state.
Перерендерте один компонент у test page та переконайтеся, що дія повторно знаходить елемент за locator.
Тест читається через предметні Page Object methods і не використовує implicit wait або довгоживучі WebElement fields.
Показує окремий business-readable step і binary screenshot attachment без додаткової wrapper abstraction.
Після запуску pytest з --alluredir report містить step Open login page і PNG attachment, якщо attach_screenshot викликано.
4. Allure репорт, основи та інтеграція в CI →Демонструє narrowing до desktop container, user-facing locators і explicit assertion; URL та labels є навчальними placeholders.
Test знаходить лише desktop form і перевіряє повідомлення про невалідний login.
3. Селектори та пошук елементів →Знайти всі збіги тексту Login у DevTools.
Побудувати locator з role/name або стабільним attribute.
Перевірити, що locator знаходить рівно один видимий element.
Дія не потребує .first або випадкового індексу.
Дані відокремлені від test body, а кожна ітерація має предметний ID.
Дві ітерації проходять і відображають IDs missing-email та missing-password.
2. Pytest fixtures, playwright fixture, прараметризація тестів →Урок оптимізує login через повторне використання стану одного користувача для кількох тестів.
Playwright гарантує ізоляцію browser contexts, але спільний акаунт і його backend data залишаються спільними; незалежність та regeneration простроченого state треба забезпечувати на рівні проєкту.
2.1. Storage state: практична реалізація, фікстури для ролей →Для перевірки видимості кнопки використовується `expect(locator).to_be_visible()`. У відео порівнюються перші варіанти локаторів: - CSS-клас: `.login-item`; - текстовий локатор: `page.get_by_text("Login")`; - точний текст: `page.get_by_text("Login", exact=True)`. Якщо локатор знаходить кілька вузлів, Playwright у strict mode не виконує дію навмання. Потрібно зробити критерій однозначним, а не бездумно брати перший елемент. `exact=True` обмежує пошук повним текстовим збігом; його документацію можна відкрити через швидку довідку PyCharm.
Після прискорення login cases нові fixtures пробують застосувати до решти suite. Для сценаріїв, яким уже потрібен авторизований користувач, planned fixture має один раз виконати login і віддати готову page. Для негативного login test, навпаки, потрібна неавторизована shared page. Автоматичний рефакторинг змінює більше тестів, ніж очікувалося, і частково плутає їх передумови. Це демонструє практичне правило: fixture називається за гарантованим станом (`anonymous_page`, `authenticated_page`), а migration робиться по одному behavior з повторним запуском, а не одним глобальним LLM-edit.
Повторний login у кожному тесті витрачає час і збільшує кількість нестабільних UI-кроків. Playwright може зберегти cookies та local storage після однієї авторизації, а нові browser contexts стартуватимуть уже в потрібному стані. Таке спільне використання допустиме лише тоді, коли застосунок дозволяє паралельні сесії одного акаунта, а тести не змінюють взаємно залежний server-side стан. `storage state` прибирає login, але не робить інші дані тестів незалежними.
[Дивитися з 17:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=1050s). Мінімальне завдання першого модуля: автоматизувати login або registration, створення community та перевірку, що після повторної авторизації збереглися введені profile data. YOY дозволяє зареєструватися на event і фактично авторизувати нового user у межах одного flow, тому test має описувати реальну state transition, а не припускати класичний окремий signup screen.
`free_project_context` відкриває context із Free state, а тест одразу перевіряє Free UI без login та ручного switch. Перший запуск виявляє проблему: fixture залежить від того, що інший тест уже створив файл авторизації. Тести не повинні залежати від порядку. Якщо state існує — він завантажується; якщо ні — fixture виконує login, перемикає проєкт, перевіряє Free plan і зберігає state сама.
Звичайний і Free flows дублювали перевірку state path, options для `new_context`, login та повернення page. Спільна функція `get_or_create_context` будує context і повідомляє, чи потрібна авторизація. Верхні fixtures залишають предметні кроки: звичайна зберігає авторизований state; Free додатково перемикає проєкт і зберігає Free state. Спільний helper не повинен поглинати ці відмінності лише заради меншої кількості рядків.
Типовий login flow проходить через frontend, backend і auth provider: клієнт надсилає ідентифікатор, provider доставляє або перевіряє challenge, backend після підтвердження видає session/token для наступних запитів. Розуміння цього маршруту показує, де саме тест блокується зовнішньою системою. У відео пропонується test-only custom header або спеціальний акаунт, за яким backend пропускає зовнішній challenge. Такий hook допустимий лише з жорстким fail-closed дизайном: production build/config його не реєструє; доступ обмежений тестовою мережею та авторизованим test service; credentials короткоживучі; використання журналюється. Перевірка одного секретного header у production-коді створює критичний auth bypass і є неприйнятною.
Наступні failures виявляються не проблемою браузера, а конфігурацією: fixture використовує неправильний base URL. Після виправлення route тести знову доходять до цільової сторінки. Також виправляється неправильний виклик `pytest.skip()` на рівні module collection. Для декларативного пропуску тесту потрібен `@pytest.mark.skip` або module-level marker; інакше pytest може пропустити весь модуль або зупинити collection не так, як очікувалося. Негативний login test відкриває sign-in route напряму. Перехід через home page і клік Login не є частиною його контракту, лише додає час і ще одну можливу причину падіння.
Pytest fixture може мати scope `session`, `package`, `module`, `class` або `function`. Чим ширший scope, тим рідше створюється ресурс: session fixture — один раз на весь test run, function fixture — окремо для кожного тесту. Код до `yield` виконує setup, а після `yield` — teardown відповідного scope. Ціль уроку — перетворити один негативний login test на параметризований. Тіло сценарію залишається одним, а різні пари email/password та читабельні case IDs передаються як дані.
`build_login_payload(email, password)` централізує структуру request body й прибирає дублювання inline dictionaries. Назва має описувати одну дію, а повернений об’єкт можна використати в кількох тестах. Секрети не слід виводити в logs навіть у допоміжних функціях.