Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Набір параметрів collection і запуску, який pytest читає з підтримуваного configuration file; pytest.ini має пріоритет над іншими legacy-форматами навіть тоді, коли файл порожній.
1. Налаштування Playwright та Pytest, простий репортінг →Перевірка format, precedence і параметрів pytest configuration files.
1. Налаштування Playwright та Pytest, простий репортінг → Першоджерело ↗Приклад створює frozen configuration і генерує пароль довжиною 10, який гарантовано порушує задану в прикладі minimum-length policy 12.
Assertions проходять, друкується student@example.test.
Підтверджує й актуалізує поняття уроку, пов’язані з Ruff configuration.
1. Фіксаємо назви файлів, рефакторинг та оптимізація під Python, підключаємо Ruff та uv → Першоджерело ↗У відео Ruff описано як спільний інструмент перевірки naming і Python style.
Ruff configuration керує rule selection через lint.select/extend-select; target-version означає мінімальну підтримувану версію Python, а не обов’язково поточний interpreter.
Приклад завантажує сусідній .env, перевіряє всі обов’язкові keys і завершується з явною помилкою, якщо конфігурація неповна.
Для підготовленого .env друкується https://example.test; при відсутньому key виникає RuntimeError.
До проєкту додаються `pydantic` і `datamodel-code-generator`. Генератор приймає локальну схему або URL, обирає `Pydantic BaseModel` як output і зберігає Python-моделі у `src/api/models`. Довгу CLI-команду краще винести в project configuration: там фіксуються input, output, версія Python і правила aliases. Згенерований файл — це стартова точка, а не готова доменна модель: автоматичні назви і надто загальні класи ще доведеться уточнювати.
Однакова конфігурація потрібна, щоб локальний запуск і CI поводилися передбачувано. У проєкті фіксуються мінімальні версії `pytest`, `pytest-playwright`, `pytest-html`, Faker та інших залежностей. Це дає IDE, pytest і CI явні передумови замість неявної залежності від локального середовища автора. На початку також показано Local History і Smart Checkout у PyCharm/IntelliJ. Ці інструменти можуть допомогти повернути локальні зміни або розібрати конфлікт під час перемикання гілки, але не замінюють Git-історію та перевірку diff.
Стартовий тест напряму викликає `driver.find_element()`, `WebDriverWait(...).until(...)` і браузерні дії. Він придатний для перевірки ідеї, але змішує бізнес-сценарій із технікою Selenium, тому наступний крок — дати діям читабельні назви й рознести їх по Page Objects. Замість Playwright `Page` у конструктор Page Object передається Selenium WebDriver. Спільний `BasePage` зберігає driver і один раз ініціалізує стандартне очікування, щоб кожен клас сторінки не дублював timeout та polling configuration. Найпрактичніше представлення локатора — tuple на кшталт `(By.CSS_SELECTOR, "...")`. Воно зберігає і стратегію, і значення пошуку та напряму сумісне з locator-based expected conditions.
Автотести розглядаються як застосунок, якому потрібна конфігурація: базові URL, email, пароль та інші параметри запуску. У корені проєкту створюється `.env`, а імена незмінних конфігурацій записуються в `UPPER_SNAKE_CASE`, наприклад `BASE_URL`, `EMAIL`, `PASSWORD`. `.env` і `.venv` додаються до `.gitignore`. Сірий файл в IDE означає, що Git його не відстежує. Важливе уточнення: `.gitignore` діє лише на невідстежувані файли. Якщо `.env` уже був закомічений, його треба прибрати з індексу; якщо секрет уже опублікований — також відкликати або змінити сам секрет.
Environment variable передає процесу значення на кшталт base URL, username або password без hardcode у вихідному коді. У Unix-подібній оболонці змінну можна експортувати перед запуском; у Windows вона задається іншим системним механізмом. `.env` є зручним локальним представленням таких пар ключ–значення, яке застосунок читає під час старту. Проблема з'являється, коли один продукт має кілька web/API/admin-сервісів і кожному потрібні окремі URL та credentials. Плоский набір ключів розростається, префікси дублюються, а залежності між значеннями стають неочевидними. Для невеликого проєкту `.env` достатній; переходити на складніший формат варто після реального зростання конфігурації.
[Дивитися з 01:30](https://www.youtube.com/watch?v=viR9Rnmxse4&t=90s). Початковий end-to-end flow: створити user, створити community, перевірити її сторінку та редагування. Уже тут видно реальні edge cases: auto-generated URL під час створення не обов’язково поводиться так само під час edit, mobile-first layout відрізняється на desktop, а payment merchant потребує окремого test configuration і не має використовувати production credentials.
Dictionary конфігурації незручний: IDE не підказує дозволені ключі, а помилки в рядках знаходяться лише під час виконання. Замість нього створюється `@dataclass(frozen=True)` з полями URL, email і password. `frozen=True` забороняє звичайне переприсвоєння полів після створення об’єкта. Це добре відповідає конфігурації одного тестового запуску: значення зчитали на старті й далі лише використовують.
Розглядаються два підходи: зберегти базовий домен і збирати адреси через f-string або одразу зберігати готові `BASE_URL` та `BASE_APP_URL`. Другий варіант обрано як простіший для поточної потреби: немає зайвої конкатенації та прихованих правил побудови адрес. Приклад f-string — `f"https://app.{domain}"`. Він корисний, коли частини адреси справді комбінуються у багатьох конфігураціях; створювати такий механізм лише «на майбутнє» суперечило б YAGNI.
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.
До Git додаються source code, Gradle Wrapper і потрібні configuration files. Не комітяться `.gradle`, `build`, `out`, локальна `.idea`, Maven build output та файли з environment variables чи secrets. Виняток для частини `.idea` може бути свідомим командним рішенням, наприклад для спільного code style. `.gitignore` має явно захищати repository від згенерованого сміття та приватних даних.