Відеобібліотека
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
У відео __init__.py пояснено як ознаку Python package і місце для публічних imports.
Для regular package це коректна практична модель, але Python 3.3+ підтримує implicit namespace packages, де namespace directory навмисно не містить __init__.py.
__init__, self, page та принципи ООП →Prompt має описувати конкретні ознаки, які треба знайти: змішані absolute/relative imports, відсутні type hints, невикористаний код, naming conventions, кеші Python. Рольова фраза на кшталт «працюй як інженер із десятьма роками досвіду» не замінює технічних критеріїв. Згенерований план обов’язково перечитується. У прикладі корисними знахідками є відсутній тип `Page`, зайві імпорти, непослідовні приватні поля та незаігнорований `__pycache__`, але частина запропонованих змін є спірною або зайвою. Спочатку важливо отримати корисний робочий тест; узгодженість структури виправляється окремим контрольованим рефакторингом.
На прикладі повторюваних рядків показано `Refactor → Introduce Variable`: PyCharm створює змінну з виділеного виразу й може замінити всі його входження. У демонстрації на macOS використовується `⌘⌥V`; на Windows або Linux слід дивитися актуальне скорочення безпосередньо в меню IDE. Так само винесено повторювані значення `classical` і `BDD` у зрозуміло названі змінні. IDE підсвічує невикористаний код сірим, тому зайві параметри й імпорти можна швидко знаходити та видаляти. Окрема команда оптимізує імпорти після змін. Для навігації показано: - `⌘B` — перейти до оголошення або реалізації символу під курсором; - `⌘⌥←` і `⌘⌥→` — повернутися до попереднього місця редагування або перейти вперед; - перехід на початок чи кінець рядка замість ручного руху курсора. Головна звичка: спочатку шукати дію в контекстному меню й дивитися її назву та скорочення, а вже потім за потреби змінювати keymap.
Хардкоджені значення замінюються на `os.getenv("BASE_URL")`, `os.getenv("EMAIL")` і `os.getenv("PASSWORD")`. Для цього імпортується стандартний модуль `os`. Плагін підтримки `.env` може дати IDE автодоповнення й підсвічування, але не є частиною виконання тестів. Реальне джерело значень — середовище процесу після завантаження `.env`.
Початкова проблема — файли названо з великої літери, хоча Python-конвенція вимагає `snake_case` і нижнього регістру для модулів. Просте ручне перейменування не гарантує, що динамічні імпорти та всі usages буде знайдено, тому спочатку потрібен аналіз повного графа використання. AI-агент отримує вузьку технічну задачу: знайти невідповідні PEP 8 назви, скласти план і виконати перейменування разом з оновленням імпортів. Для збереження Git-історії файлів використовується `git mv`. Після окремої завершеної задачі варто починати нову AI-сесію, щоб старий контекст не впливав на наступний етап.
У курсі використовується синхронний API Playwright, щоб кроки тесту виконувалися послідовно без додаткової складності `async`/`await`. Фікстуру можна типізувати класом `Page`, а PyCharm імпортує потрібне ім’я через quick fix: ```python from playwright.sync_api import Page, expect def test_open_home_page(page: Page): ... ``` Важливо імпортувати `Page` і `expect` саме з `playwright.sync_api`, а не з асинхронного API.
Наявність `__init__.py` робить директорію звичайним Python package і може визначати його зручний публічний API через imports або `__all__`. Це допомагає IDE, імпортам і читачеві зрозуміти межу модуля. Сучасний Python також підтримує namespace packages без `__init__.py`, тому файл не є абсолютною вимогою для кожної імпортованої директорії. У навчальному проєкті явний package зазвичай простіший і передбачуваніший.
Перед commit треба переглянути кожен changed file і переконатися, що до нього потрапили лише навмисні зміни. Commit message коротко описує зміст. IDE може запустити reformat code, optimize imports і code analysis; ці перевірки допомагають знайти технічні проблеми, але не замінюють ручного diff review.
У діалозі Commit перший рядок повідомлення має стисло пояснювати завершену зміну. Нижче можна додати деталі, необхідні для майбутнього пошуку й code review. Ідентифікатор задачі в повідомленні або назві гілки допомагає простежити контекст. Перед комітом IDE може виконати Reformat Code та Optimize Imports. Ці операції потрібно переглянути так само, як ручні зміни: автоматичне форматування не є гарантією коректності.
Плагін, що аналізує всю сторінку, швидко створює десятки локаторів і методів. У демонстрації результат надмірний: зайві imports, асинхронний API, складні обгортки та невдалі перевірки на кшталт `is_element_visible`. Статична перевірка видимості дає гіршу діагностику й не використовує автоматичне очікування Playwright. Для тесту краще залишати дії простими, а очікуваний стан виражати через `expect`. Велика кількість автоматично згенерованого коду збільшує обсяг підтримки, не гарантуючи стабільності.
Для наявного набору Page Objects decorators додаються через project-wide search/replace. Демонстрація показує ризик такого скорочення: regex зачіпає `__init__`, properties та неправильні відступи, після чого зміни доводиться вручну чистити й додавати imports. Після механічної зміни запускаються format check і Ruff. Це обов’язкова межа безпеки для bulk edit: результат пошуку не вважається правильним, доки diff не переглянуто, код не форматується й статичні checks не проходять.