PEP 8 naming conventions
Є первинним джерелом для module і class naming у Python.
Неймінг та структура automation-проєкту → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Java з переходом на потрібну секунду.
Терміни, нюанси та джерела
Провести naming audit одного Page Object
Зіставте class name з route, visible heading і product vocabulary.
Позначте methods, які маскують click як open, або змішують action і assertion.
Перейменуйте лише підтверджені невідповідності та запишіть два project rules у README.
Один короткий diff і два naming rules, які прибирають повторну суперечку на code review.
Python naming conventions
PEP 8 радить короткі lowercase names для modules, underscores лише коли вони покращують readability, і CapWords для class names.
Неймінг та структура automation-проєкту →Звідки брати назву Page Object
Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: `h1`, `h2`, title чи інший семантичний заголовок. Коли framework генерує сторінку переважно з `div`, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.
Функції є діями, класи й дані — іменниками
Функції Page Object називаються за дією тест-кейсу й починаються з дієслова; класи, файли, variables і constants позначають сутності або дані. Для однакових дій команда має обрати один словник — наприклад, послідовно використовувати `fill`, `click` і `select`, бажано близько до API обраного framework. Функцію, яка натискає кнопку, не варто називати `openPage`: окрема navigation-функція може відкривати URL напряму, обходячи довгий UI-шлях. Неминучі суперечки на code review краще завершити коротким naming convention у README, а не щоразу вирішувати те саме заново.
Java project, Gradle і JUnit
Створюється Java/Gradle project з group/package naming, JUnit Platform і dependencies. Відео використовує Java 11/17 і пояснює різницю Maven та Gradle як build tools. Repositories та artifact storage потрібні не лише для third-party libraries: компанія може публікувати власні clients і test artifacts. Точні dependency versions мають бути pinned і відтворювані на CI.
Jackson Databind, `@JsonProperty` і різні response shapes
Для Jackson2 deserialization явно підключається Jackson Databind. Поля JSON на кшталт `created-at`, які не відповідають Java naming conventions, мають бути явно зв’язані з fields через `@JsonProperty`. Виявляється ще одна контрактна різниця: create endpoint повертає один data object, а list endpoint — array таких objects. Одна й та сама field type не може безпечно представляти обидва shapes, тому моделі розділяються на single response і list response.
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.
Розділення за протоколом і naming conventions мов
Якщо suite працює не лише з web та HTTP API, нові верхньорівневі межі можуть з’явитися для CLI, FTP або messaging. Database і message-broker helpers можна спочатку залишити поруч з API support code, а винести вище після реального зростання. Окремо виправлено Python convention: module filenames пишуться lowercase із underscores, а class names — у PascalCase. Java class files зазвичай повторюють PascalCase класу; у TypeScript конкретна конвенція залежить від прийнятого стилю repository. Constants традиційно позначаються uppercase із underscores.
Лінтери і межі Playwright agents
Лінтер є дешевим статичним аналізатором, який автоматично підтримує частину style та naming rules. У сесії згадується окреме налаштування Python-аналізатора та його синхронізація з PyCharm. Playwright agents оцінюються як інструмент для експерименту, а не основа щоденного workflow: у практичній роботі пряме використання API та звичайне перенесення потрібного коду часто передбачуваніші. На момент сесії agents також орієнтовані насамперед на TypeScript, а не на Python чи Java bindings.
Рефакторинг, найменування та домашня практика
Автор починає з одного прямого test method, не створючи Page Object і додаткові class до появи реальної потреби. Назва method має описувати тестовий сценарій, а class — сторінку, feature, test suite або роль, яку він покриває. Невикористані імпорти прибираються через optimize imports. Домашнє завдання — відтворити короткий сценарій з авторизацією, дією на наступній сторінці та перевіркою результату.
Підсумок і практика іменування
Заняття підсумовує перехід від простого KISS-тесту, доповненого YAGNI, DRY і DAMP, до Page Object-структури з очікуваннями та двома способами перевірок: очікувати значення безпосередньо в об'єкті сторінки або повернути дані в тест для окремого порівняння. Для іменування класів, методів, змінних і тестів радять використовувати терміни, уже закладені розробниками: назви з URL, HTML та мережевих запитів, а також фактичні дії користувача. Наступні тести пропонується одразу писати через Page Object і вдосконалювати назви практикою.
Де закінчується controller
Автор порівнює `Controller`, `Service` і `API` naming. Назва вторинна; головне, щоб class не змішував domains і не ховав assertions. Не кожен endpoint потребує окремого class. Почати варто з одного resource client і розділяти, коли поточний class вже має кілька незалежних responsibilities.