Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Збережені cookies і headers для повторного використання авторизованої browser session. Такий файл може дозволити impersonation test account, тому його не слід комітити навіть у private repository; shared account підходить лише для tests без конфліктних server-side mutations.
Практика курсу на YOY, домашні завдання та формат ПМП →State-файл може містити cookies і headers, достатні для impersonation. Офіційний guide радить зберігати його поза Git навіть у private repository.
На сторінці може бути різний контент — що робити? →Trace містить actions, DOM snapshots, console і network details; це корисний debugging artifact, який може містити чутливі headers або payloads.
Як упровадити автоматизацію мануальному QA та довести її ефективність →Playwright попереджає, що state-файл може містити cookies і headers, здатні видати доступ до тестового акаунта.
2. Storage state, cookie manipulation, дебаг зникаючих елементів →`UsersApiClient` зберігає `base_url` і token, нормалізує base URL та будує authorization headers і user endpoint. Test створює client один раз і викликає intent-level methods замість ручного складання URL/header у кожному сценарії. Token усе одно не можна друкувати в logs.
`BaseController` приймає base URL і JWT, формує спільні headers `Authorization` і `Content-Type: application/json`, виконує HTTP-запит і піднімає exception для неуспішного статусу. Методи `get`, `post` і `put` повторно використовують цю поведінку; `post` і `put` додатково приймають request body. Запити варто логувати, щоб під час падіння було видно method, endpoint і контекст виклику. Для `requests` таке logging додають явно; `HTTPX` має власний logging namespace, тому конкретна реалізація залежить від обраного client.
Інкапсуляція ховає складну реалізацію за невеликою public operation. У тестовому проєкті це API clients, database helpers, Page Objects і data objects. Зовнішньому коду важливо знати, яку дію викликати, а не повторювати connection setup, headers, selectors або permission checks.
`*locators` збирає довільну кількість positional arguments у tuple, який можна перетворити на list. `**headers` збирає named arguments у dictionary. Ці форми корисні, коли кількість однотипних inputs справді змінна; для стабільного контракту явні parameters читабельніші.
SAST аналізує codebase, configuration та infrastructure definitions без запуску повного user flow. До scope можуть входити source code, dependencies, YAML, Docker та Terraform files. DAST працює проти запущеного застосунку: генерує requests, змінює parameters, headers, authentication data й шукає небезпечну runtime behavior. OpenAPI specification може бути input для API security scanner-а. Окремі tools аналізують network traffic або вразливості, характерні для конкретної мови, cloud platform, protocol чи IoT stack. Тому pentesting швидко розгалужується на спеціалізації, а не зводиться до ручного перебору requests у Postman.
Показано спрощене застосування Model–View–Controller. `Model` описує DTO і response data; `Controller` інкапсулює запити; роль view у цьому тестовому контексті не розвивається. Кожен REST resource — projects, suites, runs, templates, tests, users — отримує власний controller з потрібними операціями `create`, `get`, `update`, `delete`. Це тримає тестовий сценарій на рівні предметних дій, а URL, headers і розбір response залишаються в одному місці.
Playwright дозволяє передати частину параметрів через CLI, але для керованої конфігурації у відео перевизначаються pytest fixtures `browser_type_launch_args` і `browser_context_args`. Перша група відповідає за запуск браузера: `headless`, `slow_mo`, launch timeout і browser channel. Друга — за ізольований browser context: viewport, locale, timezone, permissions, HTTPS errors, headers, base URL та запис відео. Viewport варто обирати з підтримуваних продуктом меж. Мінімальний підтримуваний розмір часто краще виявляє перекриття й недоступні елементи, ніж великий екран розробника. При цьому viewport — це область сторінки всередині браузера, а не повний розмір системного вікна. `slow_mo` корисний для демонстрації або візуальної діагностики, але не є способом синхронізації й не повинен маскувати flaky tests. Надійний тест очікує конкретний стан через locator assertions або іншу умову, а не покладається на постійну затримку між діями.
Під час міграції можна правильно перенести service, але помилитися в gateway route: не прокинути authorization header, body або інший обов’язковий параметр. Клієнт передасть credentials, gateway прийме request, а внутрішній service поверне `401`, бо потрібний header загубився між ними. API tests швидко виявляють такі дефекти mapping, schema й routing без довгого пошуку причини через UI. Практична стратегія сесії: окремо перевіряти контракт ресурсу, окремо — ключові business flows, а під час database чи infrastructure migration запускати обидва набори як regression coverage.
Домашнє завдання — створити suite у вибраному project, отримати його через API і перевірити результат. Потім той самий підхід застосовується до test case: потрібно реалізувати `TestController`, request model, response model і перевірку створеної сутності. Базові HTTP-методи, headers, error handling і logging перевикористовуються з `BaseController`. Якщо documentation schema неповна, спершу виконується реальний request, а його JSON response перетворюється на початкову `Pydantic`-модель. Помилки validation у цьому процесі допомагають поступово відтворити фактичний контракт.