File and Code Templates
Пояснює scope custom file templates, їхні типи, налаштування і зберігання project templates.
Майструємо IDE під себе → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
File template
Шаблон PyCharm для створення нового файла з визначеними назвою, розширенням і початковим вмістом. Project-scoped templates зберігаються в .idea/fileTemplates і можуть бути спільними для команди.
Майструємо IDE під себе →Postfix completion
Описує актуальний шлях налаштування, $EXPR$, $END$ та різницю між postfix і live templates.
Майструємо IDE під себе → Першоджерело ↗Створити два postfix templates
Створіть Python postfix template locator, який обгортає вираз у page.locator(...).
Створіть postfix template expvis для expect(...).to_be_visible().
Перевірте обидва шаблони на трьох різних селекторах і переконайтеся, що лапки не дублюються.
Кожен шаблон стабільно створює синтаксично валідний Python-код, а курсор залишається в очікуваному місці.
Email-запрошення: доставлення, шаблони й eventual consistency
[Дивитися з 00:00](https://www.youtube.com/watch?v=GwmAB4IvQUk&t=0s). Запрошення учасника здається простою функцією, доки не врахувати репутацію домену, правила SMTP-провайдера, корпоративні spam-фільтри, реєстрацію застосунку, rate limits і вартість кожного листа. Окремо треба перевіряти email templates: наявність потрібного шаблону, параметризацію тексту, обов'язкові змінні та поведінку одразу після створення, коли сторонній сервіс ще може повертати закешований стан. Тест «створили template — відразу надіслали invite» може бути нестабільним не через код продукту, а через eventual consistency інтеграції.
File template для Playwright-тесту й висновки
Останній приклад — file template для нового Playwright-тесту. У ньому заздалегідь зберігається типова шапка: імпорти, базова структура тесту, потрібні фікстури та місце, де після створення файла має залишитися курсор. Назву тестової функції зрештою залишено для явного введення: автоматичне формування з назви файла не дало достатньо зручного результату. Після вибору нового типу файла в меню PyCharm створює готовий каркас, у якому можна відразу ініціалізувати потрібний Page Object і продовжити сценарій. Це завершує повний шлях автоматизації: file template створює структуру, live templates додають типові блоки, postfix templates перетворюють окремі вирази, а штатні рефакторинги безпечно змінюють уже написаний код. Практичний порядок впровадження: 1. Виписати дії та конструкції, які повторюються щодня. 2. Для кожної обрати найменший механізм: shortcut, postfix, live або file template. 3. Обмежити шаблон потрібною мовою чи контекстом. 4. Перевірити згенерований код на реальному сценарії. 5. Вимкнути невикористовувані шаблони й залишити лише ті, що справді прискорюють роботу. Налаштування IDE має зменшувати кількість механічних дій, але не приховувати зміст коду. Експериментувати варто поступово: додавати один шаблон під реальне повторення, користуватися ним у роботі й лише тоді переходити до наступного.
Рядки й явна типізація
Змінна `hello_world: str` демонструє рядковий тип. Python здатен вивести тип із правої частини, але annotation робить намір видимим у code review та допомагає IDE з автодоповненням. Для швидкого експерименту значення виводиться через `print()`. IDE postfix templates і шорткати скорочують набір коду, але результат залишається звичайним Python-викликом.
Власні postfix templates для Playwright
`Postfix Completion` налаштовується через Settings (`⌘,` на macOS). Postfix template застосовується до виразу ліворуч від крапки. Спеціальна змінна `$EXPR$` означає цей вираз, а `$END$` визначає, де залишиться курсор після розгортання. Створено кілька Python-шаблонів: - `"selector".locator` перетворює селектор на `page.locator("selector")`; - вираз із postfix `expect` обгортається в `expect(...)`; - скорочений варіант на кшталт `expvis` одразу створює `expect(...).to_be_visible()`. Під час першого налаштування `locator` вираз помилково був додатково взятий у лапки, через що PyCharm формував неправильний код. Після виправлення `$EXPR$` підставляється як готовий вираз. Це важливе правило: шаблон має додавати лише відсутню структуру, а не повторно форматувати вже валідний фрагмент. Такий ланцюжок скорочує типовий шлях до перевірки: знайти селектор, вставити його як рядок, застосувати `.locator`, а потім `.expvis`. Результат детермінований і не потребує повторної перевірки припущень генеративної моделі.
MVC як структура API-тестів
Показано спрощене застосування 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 залишаються в одному місці.
File template для Page Object
Page Object і Page Component мають повторювану основу: імпорти Playwright, клас, `__init__`, збереження `page`, базову перевірку завантаження та часто `return self`. Замість копіювання цієї «шапки» створено власний шаблон у `Settings → Editor → File and Code Templates`. У file template змінна `${NAME}` підставляє назву, яку вводять під час створення файлу. Після збереження в меню `New` з’являється окремий тип `Page Object`; вибір цього пункту створює клас з підготовленими імпортами й методами. Під час live coding шаблон кілька разів виправляється: додаються пропущені `self`, закривається дужка, коригуються відступи. Це нормальний цикл налаштування: створити пробний файл, дочекатися синтаксичних та інспекційних підказок IDE, виправити шаблон і повторити генерацію. Перевіряти потрібно саме згенерований файл, а не лише текст у вікні налаштувань. Оскільки поточні Page Object і Page Component мають однакову основу, одного file template достатньо. Окремі шаблони варто додавати лише тоді, коли їхня структура реально розійдеться.
Локатори й доступність у реальному інтерфейсі
Під час пошуку елементів для наступного тесту видно, наскільки якість HTML впливає на автоматизацію. У модальному вікні частина елементів не має зручних семантичних ознак, стабільних назв або доступних ролей. Через це доводиться розглядати `id`, текст, структуру `div` і Accessibility Tree. Кращий локатор спирається на доступну роль, ім’я або іншу стабільну продуктову ознаку. CSS-класи оформлення, випадкові вкладені контейнери й пробіли в тексті — крихка основа. Якщо елемент важко однозначно знайти, це може бути не лише проблемою тесту, а й сигналом недостатньої доступності чи тестованості інтерфейсу. Після дослідження обирається невеликий реальний сценарій: створити сутність через кнопку, заповнити назву й перевірити наступний стан. Саме повторювані частини цього сценарію далі перетворюються на live templates.
Live templates для методів і повторюваних блоків
На відміну від postfix template, `Live Template` розгортається в місці курсора з короткої абревіатури. У Settings створюється окрема група шаблонів для проєкту або Playwright, а контекст обмежується Python-файлами. Це не дає шаблону випадково з’являтися в нерелевантних типах файлів. У шаблоні методу використовуються змінні для назви функції, аргументів або локатора та `$END$` для фінальної позиції курсора. Після розгортання `Tab` переходить між редагованими полями. Якщо автоматичне перетворення назви в `snake_case` не працює передбачувано, простіше залишити явне введення назви, ніж ускладнювати шаблон. На основі реального сценарію створено заготовку методу, який приймає дані, знаходить елемент через `self.page.locator(...)`, виконує дію й повертає `self`. Потім метод перейменовується рефакторингом IDE, щоб назва оновилась і в оголошенні, і у виклику.
Дані Faker, запуск і перевірка сценарію
Для унікальної назви використовується Faker. Вираз із назвою компанії перетворюється на змінну через створений postfix template, змінна перейменовується на змістовну `target_suite_name` і передається в метод створення. Непотрібні вбудовані postfix templates можна вимикати, щоб список підказок не заважав. Водночас експеримент із власним `.var` показує межу автоматизації: якщо шаблон не залишає курсор у корисному місці, його треба виправити, а не пристосовувати робочий процес до невдалого шаблону. Сценарій запускається й проходить послідовно: авторизація, створення проєкту, закриття README, відкриття діалогу створення тесту. У режимі паузи перевіряється DOM і вибирається текст `Select suite for test`; для нього додається шаблон `get_by_text(...)`, після чого `expect(...).to_be_visible()` підтверджує появу модального вікна. Якщо попередній debug-процес ще приєднаний, повторний запуск може чекати на його завершення. Після коректного продовження або зупинки процесу тест проходить. Наприкінці тест перейменовується відповідно до перевірюваної поведінки, а не до проміжних технічних кроків.