Неймінг та структура automation-проєкту

Першим джерелом назви сторінки є route: кореневий шлях підказує home page, а змістовний path — конкретний екран. Якщо це SPA або URL не змінюється, наступним джерелом стає видима назва сторінки: h1, h2, title чи інший семантичний заголовок.

Коли framework генерує сторінку переважно з div, треба орієнтуватися на мову продукту та стабільні атрибути DOM. Мета — щоб назва в automation-коді відповідала тому, як екран уже називають користувачі й розробники.

from playwright.sync_api import Page, expect


class LoginPage:
    def __init__(self, page: Page) -> None:
        self.page = page
        self.heading = page.get_by_role("heading", name="Sign in")
        self.email = page.get_by_label("Email")

    def open(self) -> None:
        self.page.goto("/login")
        expect(self.heading).to_be_visible()

    def fill_email(self, value: str) -> None:
        self.email.fill(value)

Для кожного Page Object або повторно використовуваного компонента потрібна операція, яка доводить готовність до подальших дій. Вона локалізує причину падіння: замість випадкової помилки наступного кроку тест одразу повідомляє, що сторінка не завантажилася або потрібний блок не з’явився.

Критерій залежить від rendering strategy. У client-side rendering можуть послідовно з’являтися skeleton, дані й зображення; інша сторінка приховує весь content до завершення кількох requests. Перевіряти треба мінімальний набір елементів, без яких сценарій не може продовжуватися, а не чекати кожної можливої деталі.

Popup, який використовується на кількох сторінках, є природним кандидатом на окремий object. Назву варто шукати в його heading, data-testid, class або іншому атрибуті найближчого контейнера. Так automation-модель повторює структуру продукту й полегшує пошук коду.

Якщо test environments обфускують усі стабільні назви, це варто обговорити з frontend-командою: production може мати обфускацію, але dev/stage потребують передбачуваного test contract. Водночас не можна прив’язувати неймінг чи selectors до випадкових inline styles або кольорів.

Чим ближчі назви automation-коду до frontend і HTML, тим легше новому інженеру знайти вже реалізований object або зрозуміти, де додати нову дію. LLM можна використати як співрозмовника для добору назви, але джерелом доменної мови залишаються продукт і код команди.

Перевірка готовності компонента не повинна вимагати всіх варіативних полів. Premium badge або характеристика конкретного типу продукту можуть бути відсутні законно; isLoaded має перевіряти лише спільний мінімум.

Функції Page Object називаються за дією тест-кейсу й починаються з дієслова; класи, файли, variables і constants позначають сутності або дані. Для однакових дій команда має обрати один словник — наприклад, послідовно використовувати fill, click і select, бажано близько до API обраного framework.

Функцію, яка натискає кнопку, не варто називати openPage: окрема navigation-функція може відкривати URL напряму, обходячи довгий UI-шлях. Неминучі суперечки на code review краще завершити коротким naming convention у README, а не щоразу вирішувати те саме заново.

У REST структура починається з resources та HTTP methods. Pet, Store або User задають назви controllers/clients, а дії на кшталт create, update, delete чи find by ID — назви методів. Request і response models корисно розділяти, бо server response часто містить поля, яких не було у request.

У GraphQL треба повторювати назви queries, mutations, inputs і types зі schema. Code generation може дати готові типи, але базове правило те саме: не створювати паралельний словник там, де backend contract уже має точні терміни. Read-only доступ до frontend і backend repositories допомагає швидше зрозуміти систему й підтримувати automation разом зі змінами продукту.

Початкова структура може бути простою: спільний config, web із pages/components, api із clients/controllers та DTO, а за потреби — робота з database. Не треба заздалегідь будувати повну enterprise-ієрархію.

Коли database-код розростається, його можна винести на окремий рівень і розділити на entities та repositories/DAO. Це наступна ітерація після появи кількох tables і повторюваних CRUD operations, а не стартова вимога для першого test suite.

Великий продукт може мати B2C, B2B, back office, tool-sharing або branch-office застосунки зі спільним core. Структуру automation варто повторювати за реальними domain/app boundaries, а common-код піднімати лише тоді, коли він справді спільний.

Для нового automation effort рекомендовано починати з одного repository: розділити усталену систему пізніше простіше, ніж одразу координувати кілька репозиторіїв без перевіреної потреби. Один repository також полегшує справжні end-to-end flows через кілька доменів.

Структура каталогів не визначає правильний рівень 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.

Якщо 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.

Лінтер є дешевим статичним аналізатором, який автоматично підтримує частину style та naming rules. У сесії згадується окреме налаштування Python-аналізатора та його синхронізація з PyCharm.

Playwright agents оцінюються як інструмент для експерименту, а не основа щоденного workflow: у практичній роботі пряме використання API та звичайне перенесення потрібного коду часто передбачуваніші. На момент сесії agents також орієнтовані насамперед на TypeScript, а не на Python чи Java bindings.