Создание собственного фреймворка (в общем смысле этого слова) для автоматизации (API): почему это хорошая идея?

Введение

Привет, Habr! Меня Женя Паршин, и я инженер по автоматизации тестирования, работающий преимущественно в e-commerce. За годы работы я участвовал в десятках проектов: от небольших интернет-магазинов до крупных платформ с миллионами пользователей. В e-commerce автотесты — это не роскошь, а необходимость. Частые релизы, сложные интеграции, платежные системами и высокие требования к стабильности заставляют искать эффективные инструменты. Но готовые фреймворки не всегда идеально подходят под специфические задачи проекта.

В этой статье я расскажу, почему создание собственного фреймворка для автоматизации — это не "изобретение велосипеда", а практичное решение, особенно в e-commerce. Мы разберем, когда это полезно, какие проблемы решает, и приведем примеры из практики. В качестве иллюстрации я использую свой open-source фреймворк partest, чтобы показать, как такие инструменты работают. В конце соберем небольшой FAQ содержащий краткие ответы на все вопросы которые мы тут обсудили.

Зачем создавать свой фреймворк?

Автоматизация тестирования в e-commerce — это вызов. Проекты часто меняются и команды сталкиваются с повторяющимися задачами которые требуют кастомизации, клиенты не всегда понимают ценность автотестов - а для качественной реализации проекта они всё равно нужны. Вот несколько проблем, с которыми я сталкивался:

• Копипаст кода: В каждом проекте приходилось заново писать API-клиенты, утилиты для обработки данных, генерацию данных или парсеры спецификаций API. Это отнимает время и увеличивает риск ошибок.

• Разрозненность подходов: Разные проекты используют разные шаблоны написания тестов, что затрудняет адаптацию инженеров при переходе между задачами.

• Ограничения готовых инструментов: pytest и httpx/requests мощные, но для специфических задач, таких как отслеживание покрытия API или интеграция с e-commerce-системами, нужны дополнительные обертки.

• Частые изменения: API обновляются, и тесты нужно адаптировать. Без единого подхода это превращается в рутину.

Собственный фреймворк решает эти проблемы, позволяя:

1. Унифицировать написание тестов.

2. Централизовать обновления (например, изменение логики API-клиента).

3. Адаптировать инструмент под нужды проекта.

4. Ускорить онбординг новых инженеров.

Сценарии полезности в e-commerce

Создание собственного фреймворка приносит пользу в ситуациях, типичных для e-commerce. Вот несколько примеров из моей практики:

1. Ускорение написания тестов

В проекте для интернет-магазина мы тестировали API десятков микросервисов (каталог, корзина, контент, пользователи и т.д.). Каждый тест содержал повторяющийся код для настройки запросов и обработки ответов. Создав кастомный API-клиент, мы сократили объем кода на 20–30% и ускорили написание тестов - вместо десятка строк настройки достаточно было одного вызова с параметрами.

Диаграмма, сравнивающая количество строк кода для теста с использованием стандартного httpx/requsets и кастомного API-клиента. Ось Y — кол-во строк кода.

2. Централизованное обновление

В одном проекте API интернет-магазина перестал принимать дефолтные JSON-запросы — теперь требовалось явно указывать тип данных (Content-Type: application/json в заголовках). Без собственного фреймворка пришлось бы добавлять этот заголовок в каждый тест вручную, что заняло бы дни. С кастомным API-клиентом я обновил логику заголовков в одном месте, и все сразу заработало во всех тестах использующие клиент. Подтянув изменения из репозитория в других проектов я имею новую версию АПИ клиента. Это сократило время обновления до нескольких часов.

3. Отслеживание покрытия API

Для крупной платформы нужно было проверить, какие эндпоинты покрыты тестами и какими именно типами тестов. Я дописал в фреймворк парсер Swagger-документации в виде декоратора и подключили его к API-клиенету, он автоматически анализировал спецификацию, отлавливал вызовы которые проходили через API клиент с последующим отчетом о покрытии.

4. Гибкость без лишних зависимостей

Фреймворк не обязательно делать публичным, можно использовать его из приватного Git-репозитория. Это позволяет быстро адаптировать инструмент под специфические нужды клиента, которые могут быть секьюрными.

5. Упрощение онбординга

В e-commerce инженеры часто переключаются между проектами. Единый фреймворк помогает новым разработчикам быстрее влиться: вместо изучения разрозненных скриптов они осваивают один API-клиент и набор утилит.

Пример реализации: как работает partest

Чтобы показать, как выглядит собственный фреймворк, я приведу пример моего open-source проекта partest. Это не реклама, а демонстрация того, как можно реализовать идеи, описанные выше. Partest — это фреймворк для API-автотестов с оценкой покрытия, построенный на PyTest, HTTPX и Allure. Он включает:

• API-клиент: Гибкий клиент для HTTP-запросов с поддержкой множества параметров.

• Swagger-парсер: Для анализа покрытия API.

• Утилиты: Для быстрого форматирования данных (например, дат).

• Интеграция с Allure: Для генерации отчетов.

Настройка partest

Для работы с partest нужно создать два файла конфигурации:

1. conftest.py:

def pytest_addoption(parser):
    parser.addoption("--domain", action="store", default="http://url.ru")

@pytest.fixture(scope="session")
def domain(request):
    return request.config.getoption("--domain")
    
@pytest.fixture(scope="session")
def api_client(domain):
    return ApiClient(domain=domain)

@pytest.fixture(scope='session', autouse=True)
def clear_call_data():
    global call_count, call_type
    api_call_storage.call_count.clear()
    api_call_storage.call_type.clear()
    yield

2. confpartest.py:

swagger_files = {
    'test1': ['local', '../docs/openapi.yaml']
}

test_types_coverage = ['default', '405', 'param']
test_types_exception = ['health']

Эти файлы настраивают базовый URL, API-клиент и параметры покрытия. Например, swagger_files указывает, где брать спецификацию API, а test_types_coverage определяет типы тестов для 100% покрытия.

Пример теста

Вот как выглядит тест с использованием partest для проверки API корзины интернет-магазина:

import allure
import pytest
from partest import ApiClient
from partest.zorro_report import zorro
from pydantic import BaseModel
from data.valitations import CartResponse

@pytest.mark.asyncio
class TestCart:

    async def test_add_to_cart(self, api_client):
        response = await api_client.make_request(
            method='POST',
            endpoint='/cart/add',
            data={'product_id': 123, 'quantity': 2},
            expected_status_code=201,
            validate_model=CartResponse,
            type='default'
        )
        assert response['cart_id'] > 0
        assert len(response['items']) == 1

Параметры API-клиента

API-клиент partest принимает множество параметров для гибкости:

• method: HTTP-метод (GET, POST и т.д.).

• endpoint: Целевой эндпоинт.

• add_url1, add_url2, add_url3, after_url, defining_url: Дополнительные части URL.

• params: Query-параметры.

• headers: Заголовки запроса.

• data: Данные запроса.

• data_type: Тип данных.

• files: Файлы для загрузки.

• expected_status_code: Ожидаемый код ответа.

• validate_model: Модель для валидации ответа.

• type: Тип теста (например, default, 405).

FAQ

Скрытый текст

1. Зачем создавать свой фреймворк, если есть множество других?
Готовые инструменты универсальны, но для специфических задач, таких как тестирование API в e-commerce, часто нужны кастомные решения. Собственный фреймворк унифицирует код, ускоряет написание тестов и позволяет централизованно обновлять логику.

2. Когда это не стоит делать?
Если проект маленький (1–2 теста) или задачи не повторяются, проще использовать PyTest. Создание фреймворка оправдано, когда вы работаете с множеством проектов и хотите избежать копипаста.

3. Как интегрировать с CI/CD?
Собственный фреймворк на базе PyTest легко интегрируется с Jenkins, GitLab CI или GitHub Actions. Вы добавляете зависимости в requirements.txt и запускаете тесты через pytest. Отчеты о покрытии (например, через Allure) можно настроить в CI-дашбордах.

4. Как обеспечить поддержку фреймворка?
Для внутренних проектов обновления вносятся в Git-репозиторий с фреймворком. Для open-source, как partest, можно публиковать в PyPI.

5. Какой опыт я получу?
Создание фреймворка учит проектировать модульный код, работать с зависимостями и поддерживать проекты. Это особенно полезно в e-commerce, где важна адаптивность.

6. Чем кастомный фреймворк лучше готового?
Вы сами определяете, как он будет развиваться. Например, в partest я добавил Swagger-парсер, потому что мне нужно было отслеживать покрытие. Вы не зависите от сторонних авторов и можете адаптировать инструмент под свои задачи.

Заключение

Создание собственного фреймворка для автоматизации — это способ упростить и ускорить тестирование, особенно в e-commerce, где проекты сложные, а задачи повторяются. Вы экономите время на написании тестов, унифицируете подходы, упрощаете онбординг и получаете гибкость. Мой фреймворк partest — пример такого подхода, и вы можете попробовать его или создать свой.

Если у вас есть идеи, как улучшить подход, или вопросы по автоматизации, пишите в комментариях или в репозиторий partest. Давайте делиться опытом!