PEP 8 naming conventions
Є первинним джерелом для module і class naming у Python.
Неймінг та структура automation-проєкту → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
Ruff naming rules треба вибирати явно
У відео Ruff описано як спільний інструмент перевірки naming і Python style.
Ruff configuration керує rule selection через lint.select/extend-select; target-version означає мінімальну підтримувану версію Python, а не обов’язково поточний interpreter.
Провести naming audit одного Page Object
Зіставте class name з route, visible heading і product vocabulary.
Позначте methods, які маскують click як open, або змішують action і assertion.
Перейменуйте лише підтверджені невідповідності та запишіть два project rules у README.
Один короткий diff і два naming rules, які прибирають повторну суперечку на code review.
Good Integration Practices — pytest
Уточнює pytest layout і naming conventions.
2. Перший автотест на Python з Playwright → Першоджерело ↗`__init__.py` не є умовою pytest discovery
Pytest знаходить test modules і functions за naming conventions навіть без Python package. __init__.py впливає на import semantics і module names, але не є обов’язковим для базового discovery.
PEP 8: Package and Module Names
Підтверджує й актуалізує поняття уроку, пов’язані з PEP 8 module naming.
1. Фіксаємо назви файлів, рефакторинг та оптимізація під Python, підключаємо Ruff та uv → Першоджерело ↗Звідки брати назву Page Object
Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: `h1`, `h2`, title чи інший семантичний заголовок. Коли framework генерує сторінку переважно з `div`, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.
Ініціалізація Faker і зрозуміла назва даних
Перший виклик виправляється після звірки з API: треба створити екземпляр `Faker()`, а вже потім викликати його provider, наприклад `fake.password(length=10)`. Повторні запуски демонструють різні значення. Змінна називається `invalid_password`, щоб тест явно пояснював роль даних. Практична межа рандомізації: при падінні варто логувати або зберігати згенероване значення чи seed, інакше дефект може бути важко відтворити.
Структура тестів і правила іменування
Тести зручно тримати в окремому Python package, а не у випадковій директорії. Package містить `__init__.py`, що явно позначає Python-структуру. Для автоматичного виявлення pytest файл і тестова функція мають відповідати домовленостям іменування, наприклад: ```python def test_open_home_page(): ... ``` Назви Python-файлів, функцій і змінних записуються у `snake_case`. Підкреслення PyCharm та індикатор проблем у правому верхньому куті не варто ігнорувати: вони часто показують синтаксичну або типізаційну помилку ще до запуску.
Перейменування Python-файлів без зламаних імпортів
Початкова проблема — файли названо з великої літери, хоча Python-конвенція вимагає `snake_case` і нижнього регістру для модулів. Просте ручне перейменування не гарантує, що динамічні імпорти та всі usages буде знайдено, тому спочатку потрібен аналіз повного графа використання. AI-агент отримує вузьку технічну задачу: знайти невідповідні PEP 8 назви, скласти план і виконати перейменування разом з оновленням імпортів. Для збереження Git-історії файлів використовується `git mv`. Після окремої завершеної задачі варто починати нову AI-сесію, щоб старий контекст не впливав на наступний етап.
Технічний prompt і ревізія запропонованого плану
Prompt має описувати конкретні ознаки, які треба знайти: змішані absolute/relative imports, відсутні type hints, невикористаний код, naming conventions, кеші Python. Рольова фраза на кшталт «працюй як інженер із десятьма роками досвіду» не замінює технічних критеріїв. Згенерований план обов’язково перечитується. У прикладі корисними знахідками є відсутній тип `Page`, зайві імпорти, непослідовні приватні поля та незаігнорований `__pycache__`, але частина запропонованих змін є спірною або зайвою. Спочатку важливо отримати корисний робочий тест; узгодженість структури виправляється окремим контрольованим рефакторингом.
Функції є діями, класи й дані — іменниками
Функції Page Object називаються за дією тест-кейсу й починаються з дієслова; класи, файли, variables і constants позначають сутності або дані. Для однакових дій команда має обрати один словник — наприклад, послідовно використовувати `fill`, `click` і `select`, бажано близько до API обраного framework. Функцію, яка натискає кнопку, не варто називати `openPage`: окрема navigation-функція може відкривати URL напряму, обходячи довгий UI-шлях. Неминучі суперечки на code review краще завершити коротким naming convention у README, а не щоразу вирішувати те саме заново.
Великі зміни через план-файл і короткі сесії
Для великої міграції план доцільно зберегти в окремому Markdown-файлі й виконувати по одному пункту в нових сесіях. Це зменшує ризик, що модель втратить початкові обмеження у довгому контексті або спробує змінити забагато файлів за один раз. Стабільні правила проєкту — структура, команди, naming, бібліотеки та перевірки — корисно тримати у спільному інструкційному файлі на кшталт `AGENTS.md`. Тимчасовий migration plan можна не комітити, якщо він потрібен лише для локальної роботи.
`model_validate()`, aliases і форма response
`PydanticModel.model_validate(response_data["data"])` перетворює dictionary на типізований object і водночас перевіряє schema. Модель suite зводиться до реальних полів на кшталт `id`, `type`, `attributes` і `relationships`, а зайві generated wrappers видаляються. Якщо JSON-ключ не є коректним Python-ідентифікатором, наприклад містить дефіс, для поля задається alias. У коді зберігається `snake_case`, а `Pydantic` зіставляє його з оригінальною назвою в JSON.
Ruff як спільне правило якості коду
IDE inspections залежать від локальних налаштувань кожного інженера. `Ruff` переносить правила у репозиторій: перевіряє naming, невикористані імпорти, частину потенційних помилок і може форматувати код значно швидше за традиційний набір Python-інструментів. У PyCharm вмикається інтеграція Ruff, а в Actions on Save — reformat та optimize imports. Налаштування зберігаються в `ruff.toml` або секції `pyproject.toml`; версія Python у конфігурації має відповідати реальному runtime проєкту.
Testing trophy, статичний аналіз і мовні layout conventions
Структура каталогів не визначає правильний рівень coverage. Для сучасних frameworks часто корисніше мислити test trophy або testing landscape: поєднувати static analysis, component/integration tests і лише потрібні end-to-end tests відповідно до ризику конкретної частини системи. У Java типовий layout має `src/main` і `src/test` із packages; Python та TypeScript часто відділяють application/support code від tests простіше. Naming і package layout треба брати з conventions мови та поточного repository, а не переносити механічно з іншого stack.