Как QA Auto, сталкиваюсь с тем, что фреймворки начинают «болеть» при росте команды и количества тестов. Главные симптомы запущенного проекта — хаос в фикстурах, циклические импорты и тесты, которые знают слишком много о внутренностях системы.

Эффективный фреймворк на Python + pytest должен быть построен по принципу слоистой архитектуры (Layered Architecture). Тесты должны читать как бизнес-сценарии, а вся техническая реализация (селекторы, отправка запросов, подключение к базам) — скрываться под капотом. Ниже представлена проверенная структура и пошаговый план реализации, который легко масштабируется под UI (Playwright/Selenium) и API тестирование.

🛠️ Пошаговый план реализации

Чтобы не закопаться в рефакторинге, фреймворк лучше собирать снизу вверх: от конфигурации к тестам.

1.Шаг 1: Конфигурация и инфраструктура:

Базовый фундамент. Настройте pytest.ini (задайте базовые маркеры, логирование и пути). Используйте pydantic-settings или python-dotenv для изоляции конфигураций окружений. Создайте корневой tests/conftest.py, который будет читать конфиги и инициализировать базовые утилиты (например, логирование).

2.Шаг 2: Создание Core-слоя (Клиенты и Драйверы): Слой абстракции над протоколами. Напишите BaseClient для API (добавьте туда автоматическое логирование запросов/ответов в Allure) и BasePage для UI (оберните стандартные методы ожидания элементов, чтобы избежать flaky-тестов). На этом этапе тестов еще нет — только инструменты.

3.Шаг 3: Бизнес-моделирование (POM / API Actions):

Описание логики приложения. Создайте конкретные классы страниц (LoginPage, DashboardPage) или API-сервисов (UserServices). Главное правило: никаких ассертов внутри этих классов. Они только выполняют действия и возвращают данные или другие страницы.

4.Шаг 4: Организация фикстур в pytest:

Управление состоянием. Используйте вложенные файлы conftest. Фикстуры для инициализации браузера или авторизации в API должны лежать в соответствующих папках tests/ui/conftest.py и tests/api/conftest.py. Это исключит путаницу и ускорит сбор тестов. Используйте scope=“session” для тяжелых фикстур (авторизация, коннект к БД).

5.Шаг 5: Написание тестов и репортинг:

Финальный слой. Пишите тесты, используя паттерн AAA (Arrange, Act, Assert). Интегрируйте allure-pytest: размечайте шаги через @allure.step внутри Page Objects, чтобы отчеты были понятны даже ручным тестировщикам и PM.

3 паттерна и лучшие практики для этого стека:

1. Вложенные conftest (Scoping): pytest ищет фикстуры снизу вверх. Разнося фикстуры по подпапкам tests/api/ и tests/ui/, вы гарантируете, что UI-тесты не потащат за собой фикстуры для настройки базы данных, нужные только в API.

2. Data-Driven Testing через pytest.mark.parametrize: Не дублируйте тесты ради разных входных данных. Используйте параметризацию. Если данных много — выносите их в json или yaml файлы в папку config/ или tests/test_data/.

3. Паттерн Steps (для API): Вместо вызова методов API-клиента напрямую в тесте, объединяйте их в цепочки бизнес-действий (например, UserSteps.create_and_activate_user()). Что сделает код тестов чистым и защитит от изменений в API (если изменится контракт — поменяем только в Steps).

Важно помнить: Избегайте использования синглтонов для драйверов браузера или API-сессий «в лоб». В pytest управление жизненным циклом объектов должно полностью лежать на фикстурах (yield), иначе вы столкнетесь с кучей проблем при попытке запустить тесты параллельно через pytest-xdist.

🎭 Как это выглядит со стороны теста

Благодаря такой магии в conftest сам тест пишется невероятно чисто. Ему не нужно знать, как поднимается браузер, как закрывается страница и где берутся Page Objects. Вы просто запрашиваете нужные страницы в аргументах функции:

можно посмотреть на последнем скриншоте