Введение
Привет, Habr! Меня Женя Паршин, и я инженер по автоматизации тестирования, работающий преимущественно в e-commerce. За годы работы я участвовал в десятках проектов: от небольших интернет-магазинов до крупных платформ с миллионами пользователей. В e-commerce автотесты — это не роскошь, а необходимость. Частые релизы, сложные интеграции, платежные системами и высокие требования к стабильности заставляют искать эффективные инструменты. Но готовые фреймворки не всегда идеально подходят под специфические задачи проекта.
В этой статье я расскажу, почему создание собственного фреймворка для автоматизации — это не "изобретение велосипеда", а практичное решение, особенно в e-commerce. Мы разберем, когда это полезно, какие проблемы решает, и приведем примеры из практики. В качестве иллюстрации я использую свой open-source фреймворк partest, чтобы показать, как такие инструменты работают. В конце соберем небольшой FAQ содержащий краткие ответы на все вопросы которые мы тут обсудили.
Зачем создавать свой фреймворк?
Автоматизация тестирования в e-commerce — это вызов. Проекты часто меняются и команды сталкиваются с повторяющимися задачами которые требуют кастомизации, клиенты не всегда понимают ценность автотестов - а для качественной реализации проекта они всё равно нужны. Вот несколько проблем, с которыми я сталкивался:
Копипаст кода: В каждом проекте приходилось заново писать API-клиенты, утилиты для обработки данных, генерацию данных или парсеры спецификаций API. Это отнимает время и увеличивает риск ошибок.
Разрозненность подходов: Разные проекты используют разные шаблоны написания тестов, что затрудняет адаптацию инженеров при переходе между задачами.
Ограничения готовых инструментов: pytest и httpx/requests мощные, но для специфических задач, таких как отслеживание покрытия API или интеграция с e-commerce-системами, нужны дополнительные обертки.
Частые изменения: API обновляются, и тесты нужно адаптировать. Без единого подхода это превращается в рутину.
Собственный фреймворк решает эти проблемы, позволяя:
Унифицировать написание тестов.
Централизовать обновления (например, изменение логики API-клиента).
Адаптировать инструмент под нужды проекта.
Ускорить онбординг новых инженеров.
Сценарии полезности в e-commerce
Создание собственного фреймворка приносит пользу в ситуациях, типичных для e-commerce. Вот несколько примеров из моей практики:
1. Ускорение написания тестов
В проекте для интернет-магазина мы тестировали API десятков микросервисов (каталог, корзина, контент, пользователи и т.д.). Каждый тест содержал повторяющийся код для настройки запросов и обработки ответов. Создав кастомный API-клиент, мы сократили объем кода на 20–30% и ускорили написание тестов - вместо десятка строк настройки достаточно было одного вызова с параметрами.
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 нужно создать два файла конфигурации:
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
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. Давайте делиться опытом!
