Good Integration Practices — pytest
Уточнює pytest layout і naming conventions.
2. Перший автотест на Python з Playwright → Першоджерело ↗Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
`__init__.py` не є умовою pytest discovery
Pytest знаходить test modules і functions за naming conventions навіть без Python package. __init__.py впливає на import semantics і module names, але не є обов’язковим для базового discovery.
PEP 8 naming conventions
Є первинним джерелом для module і class naming у Python.
Неймінг та структура automation-проєкту → Першоджерело ↗Python naming conventions
PEP 8 радить короткі lowercase names для modules, underscores лише коли вони покращують readability, і CapWords для class names.
Неймінг та структура automation-проєкту →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.
Технічний 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, а не щоразу вирішувати те саме заново.
Access modifiers і зближення мов
Java і C# формально перевіряють `public`, `private` та `protected`, тоді як Python використовує переважно conventions. Водночас суворіші мови скорочують boilerplate, а Python і JavaScript додають type hints та інструменти статичного аналізу. Python annotations допомагають IDE й type checker, але самі по собі не перетворюють Python на статично типізовану мову та не гарантують runtime-перевірку. Їхня користь — ранній зворотний зв’язок і краща навігація по API.
Розділення за протоколом і 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.