`__init__.py` не є умовою pytest discovery
Pytest знаходить test modules і functions за naming conventions навіть без Python package. __init__.py впливає на import semantics і module names, але не є обов’язковим для базового discovery.
Відеобібліотека
Знайди точне пояснення
Пошук у нотатках курсу Python мануфактура та спільних матеріалах з переходом на потрібну секунду.
Терміни, нюанси та джерела
test discovery
Правила, за якими pytest знаходить test modules і test functions; рекомендований базовий шаблон — test_*.py і функції з префіксом test_.
Оголошення, parameters, type hints і `return`
Функція оголошується через `def`, приймає named parameters і може повертати значення. Type hints на кшталт `email: str` та `-> dict[str, str]` покращують navigation і IDE checks, але самі по собі не валідовують input at runtime.
Вкладені функції та scope
Функцію можна оголосити всередині іншої, тоді вона доступна лише в зовнішньому function body. Це інколи допомагає розкласти великий transform, але single-use nested helper не завжди покращує код. Якщо логіка потрібна в кількох місцях, її краще зробити звичайною module-level function із чітким контрактом.
Типізовані дані як наскрізний контракт
Між functions передають типізовані `UserDto`, `ProductDetails`, `CompanyDetails` або інші domain types замість розрізнених primitive values. Це робить required fields видимими, спрощує повторні assertions і зменшує ризик переплутати дані. Конкретні приклади реалізації розгортаються далі в курсі.
Standard library, flaky tests і прості принципи дизайну
Middle має орієнтуватися у standard library та основних конструкціях мови: collections, functions, reserved words/operators, способи створення й перетворення даних. Це дає змогу використовувати вбудовані можливості замість зайвих dependencies і custom wrappers. Окремий практичний блок — діагностика flaky tests: відрізнити проблему очікування, нестабільні дані, shared state, зовнішню залежність або справжню race condition. `retry` не є виправленням першопричини. Для дизайну automation code достатньо впевнено застосовувати KISS, DRY, YAGNI та DAMP. SOLID і design patterns корисні як словник для конкретних проблем, але не як вимога створювати багатошарову архітектуру. Також потрібно вміти запускати suite у CI та читати test report.
Функції є діями, класи й дані — іменниками
Функції Page Object називаються за дією тест-кейсу й починаються з дієслова; класи, файли, variables і constants позначають сутності або дані. Для однакових дій команда має обрати один словник — наприклад, послідовно використовувати `fill`, `click` і `select`, бажано близько до API обраного framework. Функцію, яка натискає кнопку, не варто називати `openPage`: окрема navigation-функція може відкривати URL напряму, обходячи довгий UI-шлях. Неминучі суперечки на code review краще завершити коротким naming convention у README, а не щоразу вирішувати те саме заново.
Live templates для методів і повторюваних блоків
На відміну від postfix template, `Live Template` розгортається в місці курсора з короткої абревіатури. У Settings створюється окрема група шаблонів для проєкту або Playwright, а контекст обмежується Python-файлами. Це не дає шаблону випадково з’являтися в нерелевантних типах файлів. У шаблоні методу використовуються змінні для назви функції, аргументів або локатора та `$END$` для фінальної позиції курсора. Після розгортання `Tab` переходить між редагованими полями. Якщо автоматичне перетворення назви в `snake_case` не працює передбачувано, простіше залишити явне введення назви, ніж ускладнювати шаблон. На основі реального сценарію створено заготовку методу, який приймає дані, знаходить елемент через `self.page.locator(...)`, виконує дію й повертає `self`. Потім метод перейменовується рефакторингом IDE, щоб назва оновилась і в оголошенні, і у виклику.