Как улучшить TTM выкатки сервиса и ускорить пайплайн автотестов

Базово пайплайн чаще всего состоит из 4 шагов:

1. Сборка образа приложения
2. Запуск приложения
3. Сборка образа тестов
4. Запуск автотестов

Теперь вопрос — что тут можно реально ускорить?

Если говорим про Python, то первое что можно оптимизировать — сборку образов.

Большинство до сих пор используют pip, но есть еще как минимум:
— Poetry
— uv

И вот uv сейчас выглядит очень интересно. За счет того что он написан на Rust — установка зависимостей работает в несколько десятков раз быстрее.

На практике только за счет замены pip - uv можно спокойно срезать около минуты на старте сервиса и сборке контейнера.

Ту же самую оптимизацию можно провернуть и для образа автотестов.

Второй момент, который кажется очевидным, но как выяснилось — не для всех 😄

Python тесты можно запускать параллельно.

Золотой стандарт сейчас — pytest-xdist

Он позволяет реально запускать тесты в несколько процессов/воркеров.

Даже на обычном маке ускорение может быть x4-x8 в зависимости от количества ядер.

Пример:

pytest -n auto 

или

pytest -n 8 

Если используете аллюр:

pytest -n auto --alluredir=allure-results 

Полезные плагины:
— pytest-parallel
— pytest-concurrent
— pytest-asyncio-concurrent

Но тут важно понимать — они подходят только если тесты не конфликтуют между собой и могут безопасно работать конкурентно.


Следующий уровень оптимизации — запускать не все тесты.

Например:
у вас 1000+ тестов, но изменения затронули только платежи.

Зачем гонять вообще весь регресс?

Можно размечать тесты по фичам через markers и запускать только нужные.

Пример:

@pytest.mark.payments 
def test_create_invoice():     
    ... 

Запуск:

pytest -m payments 

Или через Allure labels/tags:

@allure.feature("Payments")
@allure.story("Invoices")

Еще один огромный bottleneck — подготовка тестовых данных.

На сложных интеграционных сценариях подготовка данных может занимать больше времени чем сами тесты.

Что можно сделать:

— вынести подготовку данных в отдельный сервис
— складывать подготовленные данные в БД
— отдавать их тестам через API
— использовать session fixtures
— готовить данные фоном во время тестовой сессии

Например:
пока идут первые тесты — в фоне уже готовятся данные для следующих.

Хранить это можно хоть в SQLite, Redis или отдельной тестовой БД.

Еще хороший кейс — авторизация.

Очень часто вижу как тест:
— логинится
— получает токен
— делает запрос
— заканчивается

И так 500 раз подряд 😄

Хотя можно сделать клиент который:
— фоново обновляет токен
— кеширует его
— следит за TTL
— отдает уже актуальный access token тестам

В итоге минус сотни лишних запросов в auth сервис.

Если суммировать, то основные точки ускорения это:

- Быстрая сборка образов
- Параллельность
- Конкурентность
- Запуск только нужных тестов
- Предподготовка тестовых данных
- Фоновые задачи
- Кеширование авторизации

И за счет этого можно очень сильно срезать время прохождения пайплайна и улучшить TTM выкатки

TG-сообщество | Обучение |Отзывы

Материалы для тех, кто в теме.

Одна из самых больших проблем при развитии в IT - это возможность найти доступный материал не для новичков.

Помню, когда я был в автоматизации тестирования, у меня был момент, когда я понимал, что на текущем месте и в текущем коллективе я самый крутой, но от этого было не весело, от этого было грустно.

Я начал смотреть другие вакансии, какие там есть технологии, чтобы была возможность развиваться.

Я обсуждал это со своими друзьями-коллегами, и тогда мне дали контакт человека, который уже работал в нашей компании, но ушёл в другую. С их слов, он был очень крутой, и честно - не хотели делиться его контактом, потому что боялись, что он меня переманит.

Справедливости ради, в дальнейшем он предложил мне перейти к ним - это уже другая история, но я сейчас о другом.

Мне дали его контакт в линке и я ему выложил всю свою боль как на духу.
Мы быстро нашли общий язык и он меня понял)
В тот момент я получил новый виток развития. Я узнал от него о тогда ещё не такой популярной теме, как кодогенерация, про настройку пайплайнов для обновления пакетов. Тогда я уже умел писать код, но не понимал, как с этим работать. Он не сказал, что и как мне делать, но поселил во мне идеи и подходы.

Это был один из самых интересных периодов в моей карьере, я был первопроходцев в своем отделе и почти все делал с нуля, просто находил и писал людям которых даже не знал, чтобы они рассказали мне как настроить пайплайн и воткнуть туда кодген. С настальгией вспоминаю, как после работы сидел с 7 вечера до 5 утра чтобы завести пайплайн и какое было ощущение счасться когда все начало работать. Сейчас с клаудкодом или другой ИИ-шкой я бы сделал это быстрее, но какой было ощущение победы, я думаю многим оно знакомо)

Этого стимула мне хватило ещё на два года. Если смотрели мою историю, то там как раз есть раздел про кодогенерацию - только изначально я писал её сам, а потом узнал, что есть готовые инструменты, и стал использовать их.

Потом я всё равно вернулся в разработку собственных инструментов, и у меня есть проекты, например такие как pbreflect, restcodegen, e2efast.

К чему я это всё? Если честно, мне иногда кажется, что я несу некую миссию для таких же заблудших душ, каким был я после трёх лет в автоматизации тестирования, которые уже и не новички, но чувствуют, что есть куда расти, и не понимают, как и что можно улучшить в своём текущем коде или процессах.

Так что если вы сейчас читаете это и узнаёте себя - вы не одни. Я здесь как раз для того, чтобы показывать, что за горизонтом есть ещё куча всего интересного. Вопрос только в том, чтобы найти своего проводника. Или стать им для кого-то)

TG-сообщество | Обучение |Отзывы

Несколько месяцев назад я спросил, какой технический тренинг вам был бы действительно интересен.

Из всех вариантов больше всего реакций и комментариев собрала тема брокеров сообщений.

Это не удивительно.
Знания Kafka, RabbitMQ встречаются всё чаще в вакансиях а у многих нет возможности даже пощупать эти технологии, не говоря уже об автоматизации, которая значительно отличается от темы REST API или UI.
Качественных материалов, которые объясняют не только “как настроить”, но и “как это работает на самом деле”, не так много. Особенно если смотреть на материалы для QA, автоматизаторов и инженеров, которым важно понимать систему целиком.

Курс уже обкатан на нескольких потоках и хорошо себя зарекомендовал.
Получился именно тот тренинг, который мне самому хотелось бы пройти несколько лет назад, когда приходилось собирать знания по кусочкам делая много проб и ошибок.

Так что уже совсем скоро стартуем, 15 июня. Приходи, будет интересно.

Это последний поток по текущей стоимости, более того я подготовил скидку 10% по промокоду DIS10
5 поток будет уже дороже.

Спасибо всем, кто когда-то проголосовал за эту тему.
Фактически именно благодаря вашему интересу этот курс появился.

Так же напомню про уже проверенный тренинг REST API Advanced, который позволит вам понимать как грамотно строить архитектуру тестового фреймворка. Это полезно всем, особенно тем кто использует нейросети, чтобы можно было валидировать результат работы ИИ.

Так что всех жду и сразу анонсирую, стоимость тренингов будет повышена.

IT меняется быстрее, чем мы успеваем привыкнуть.
У нас в команде недавно начали обкатывать новый процесс разработки и пока это очень непривычно.

Как это выглядит:
- Человек планирует фичу и запускает скиллы, которые формируют спеку и тикеты
- Агент читает тикет и пишет код
- Коллеги запускают своих агентов на код-ревью
- Агент вычитывает комментарии из ревью в GitLab, вносит правки, и так по кругу, задача может пройти несколько этапов ревью и правок автономно без участия людей.
- Когда агентское ревью пройдено, подключаются люди: смотрят на решение со своим опытом и контекстом
- Финальное решение за человеком: можно ли это катить, насколько правильно написано, соответствует ли внутренним стандартам.

Параллельно мы продумываем скиллы и линтеры, чтобы держать агентов в рамках хорошего кода и внутренних стандартов.

Получается, человек теперь на входе и на выходе:
- в начале он думает, что и зачем делать
- в конце решает, готово ли это к продакшену.
- а середину всё больше берут на себя агенты.

Честно, это вызывает непривычные чувства.
Большую часть карьеры я сам планировал и продумывал каждую обработку и каждый алгоритм.
В какой-то момент была даже лёгкая депрессия, потому что казалось что агент забрал на себя самое вкусное.

Но сейчас я понимаю: сейчас IT просто строится немного по-другому.
Раньше ты писал и использовал библиотеки, а теперь своего рода библиотекой стал skill.
И всё больше времени уходит на то, чтобы писать именно скиллы: формулировать правила, по которым агент будет работать.

Что это значит для моих курсов
Из этого есть важный вывод. Код теперь пишет агент, а от человека требуется понимать, какой код правильный и почему.
Чтобы написать агенту хорошие правила, нужно глубоко понимать архитектуру и устройство систем.

Поэтому курсы Starter и Professional я убрал с продажи: они в основном учили двум крайностям одного процесса разработки.
- Starter просто накидать что-то рабочее, с этим сейчас прекрасно справляется агент
- Professional автоматизация развертывания и генерация кода, с чем так же прекрасно справляется агент если правильно описать ему skill.
Поэтому сейчас как мне кажется они уже не так актуальны.

НО! Курсы Advanced и Brokers остаются.
Именно они дают ту базу, которая позволяет понимать какой код хороший и без которой не получится задать агенту хорошие правила.

А как у вас изменилась работа с внедрением ИИ?
Когда вы последний раз писали код руками?

У меня часто есть ощущение, что я делаю что-то недостаточно хорошо и не до конца правильно использую инструменты.

Поэтому я всегда экспериментировал с архитектурой и подходами в своих фреймворках и переписывал по куче раз прежде чем прийти к варианту которому можно учить.

С агентами та же история. Я периодически поглядываю материалы на эту тему и вечно пытаюсь в голове описать процесс так чтобы он выглядел структурировано и системно.

Че хочу сказать, несмотря на то, что платные модели сейчас очень умные, лучше задавать им рамки и правила.
Общаясь с подписчиками, я понял, что многие этого не делают и используют агентов только как чат, это абсолютно нормально. Сразу отмечусь что я НЕ ИИ гуру, но мне кажется, это не самый эффективный способ, особенно когда нужно сделать большой объём работы.

Поэтому поделюсь одним из наборов скиллов, которым пользуюсь почти каждый день, может кому-то окажется полезным.

Superpowers.
Расскажу, что он даёт.
В чате процесс держите вы: когда уточнить задачу, когда проверить, когда попросить тесты. На большом объёме контекст разрастается, ранние решения теряются, и уже непонятно, что сделано и что проверено.

Superpowers переносит процесс в скиллы, а за вами остаются решения.
Что внутри?
- brainstorming: до первой строки кода агент задаёт уточняющие вопросы и предлагает варианты. На выходе получается спека, которую легко поправить.
- writing-plans: спека превращается в план из маленьких задач с понятной проверкой. Если агент понял задачу не так, это видно сразу.
- субагенты: каждую задачу из плана выполняет отдельный субагент со свежим контекстом. Для большого объёма это главное, сессия не раздувается.
- worktree: работа идёт в отдельном git worktree. Основная ветка остаётся чистой, неудачную попытку легко выбросить ну и это позволяет работать над несколькими задачами одновременно.
- TDD: сначала падающий тест потом под него правка. Если тест написан после кода и сразу прошёл, неизвестно, поймал бы он ошибку.
- systematic-debugging: сначала воспроизвести проблему, сформулировать гипотезу и подтвердить её, и только потом чинить.
- verification: «готово» только после прогона проверок.
- code review: изменения смотрит отдельный субагент без «замыленного глаза».
- writing-skills: упаковка стандартов команды в свои скиллы.

Где это избыточно?

Для правки в одну строку брейншторм и план - смысла нет, слишком много приседаний.
Что важно отметить, что Superpowers как и другие скилы учит агента работать по шагам, но не знает, каким должен быть хороший код в вашем проекте.
Это по-прежнему задача человека.

Установка в Claude Code
Репа тут https://github.com/obra/superpowers

А чем вы пользуетесь чтобы задать агенту рамки?

Привет совсем забыл сказать!

Уже на следующей неделе 19.10 у меня стартуют тренинги.
Автоматизация тестирования брокеров сообщений

Результат: Научитесь автоматизации тестирования сложных асинхронных систем. Напишите клиенты для kafka и rabbitmq, автоматизируете длинные интеграционные сценарии, проходящие проходящие через 2 API, 2 Брокера сообщений, почтовый сервер. Научитесь работать с многопоточностью. Изучите новые архитектурные приемы и паттерны, овладеете сложной темой востребованной на рынке. Да и просто станете круче как инженеры.

🗓 Неделя 1: Kafka Producer
7 Уроков. Поговорим про брокеры сообщений, как они устроены, научимся публиковать сообщения в топики, узнаем когда нужно работать с кафка в автотестах и зачем.

🗓 Неделя 2: Kafka Consumer
5 Уроков. Научимся использовать паттерны проектирования singleton и observer, будем использовать python потоки и примитивы синхронизации. Будем слушать топики и научимся работать с блокирующими задачами. И рассмотрим проблемы которые возникают при тестировании брокеров сообщений.

🗓 Неделя 3: RabbitMQ
5 Уроков. Научимся работать RabbitMQ, узнаем что такое обменники, очереди, будем публиковать и слушать сообщения из очереди.


REST API Advanced

Результат: Вы создадите production-ready фреймворк с архитектурой уровня энтерпрайз систем. Сможете с нуля настроить CI/CD pipeline с метриками и уведомлениями. Одного моего друга пригласили на Senior позицию, после того как он показал свой проект и рассказал, что и как он сделал.

🗓 Неделя 1: Введение в автоматизацию тестирования

10 уроков. Повторим основы Python, научимся генерировать простой код, рассмотрим базу API тестирования, напишем первые тесты и настроим автоматический прогон тестов в GitHub.

🗓 Неделя 2: Архитектура и работа с данными

4 урока. Научимся использовать паттерны проектирования для решения наших задач. А также научимся подготавливать тестовые данные и рассмотрим различные виды фикстур.

🗓 Неделя 3: Проверки

7 уроков. Рассмотрим все возможные виды проверок для API, научимся валидировать структуру данных и значения. Мягкие проверки, функции-чекеры, менеджеры контекста. Будем внедрять так, чтобы не засорять код и делать его более читаемым и поддерживаемым.

🗓 Неделя 4: Работа с конфигурациями и репортинг

7 уроков. Завершающая неделя: научимся собирать Docker образы, настраивать пайплайны, дорабатывать сторонние библиотеки, собирать coverage покрытия сервиса автотестами, строить красивые и информативные отчёты. Научимся отправлять отчёты о прохождении тестов в Telegram и перепишем пайплайн для GitLab CI.

Приходи тебе точно пригодится!

Привет, не все же про ИИ говорить, давайте поговорим про инженерное программистское, потому что эту культуру тоже лучше поддерживать.

И хочу про очень интересную тему поговорить, многим может и не надо, можно же у ИИ спросить, но чето публиковать в канале надо же)

И тема эта Dependency Injection.

Так вот DI (Dependency Injection) - внедрение зависимостей.
Это принцип, при котором объект не создаёт нужные ему объекты сам, а получает их извне.

Разберём на примере кода из моего тренинга:

class DMApiAccount:
    def __init__(self, configuration: Configuration):
        self.login_api = LoginApi(configuration=configuration)
        self.account_api = AccountApi(configuration=configuration)

Что тут не так?
Api-клиенты создаются внутри DMApiAccount, который по сути фасад для API сервиса.

Это осознанное допущение: DMApiAccount - единственная входная точка, и одна фикстура создаёт всё остальное. Это нормально, если пользоваться осознанно и не злоупотреблять.

Почему это плохо?
Такой код сложнее тестировать: придётся лезть в свойства и подменять клиенты руками.
Каждый DMApiAccount создаёт ещё два клиента вместо того, чтобы переиспользовать существующие.
А с БД это могут быть ещё и лишние соединения.

Из болей я встречал фреймворки, где инстансы создавали не только в конструкторе, но и в каждом методе, там беспощадно использовали singleton, и рефакторинг такого кода требовал переписывать каждый метод и каждый конструктор, это полная жопа))

Как правильно?

Использовать DI:

class DMApiAccount:
    def __init__(self, login_api: LoginApi, account_api: AccountApi):
        self.login_api = login_api
        self.account_api = account_api

config = Configuration()
dm_api = DMApiAccount(
    login_api=LoginApi(configuration=config),
    account_api=AccountApi(configuration=config),
)

Теперь любую зависимость легко подменить на мок или другой класс с такими же методами (через Protocol или ABC).

Но согласитесь, собирать всё это руками геморно, а таких классов во фреймворке может быть очень много. Для упрощения этой задачи есть библиотеки, которые строят DI Container, и вот одна, которая мне очень нравится: https://github.com/troyan-dy/nuke-di

DI-контейнер в ней сам создаёт инстансы по аннотациям типов.

Условие одно: клиенты наследуются от nuke_di.Client.

class LoginApi(Client): ...

class AccountApi(Client): ...

@dataclass
class DMApiAccount(Client):
    _login_api: LoginApi
    _account_api: AccountApi

    async def do_smth(self) -> None: ...

async def main():
    dm_api_account = DI.resolve(DMApiAccount)
    async with DI:
        await dm_api_account.do_smth()

Резолвим только DMApiAccount, остальное DI создаст сам.

Ещё одна крутая штука - у каждого клиента есть connect() и disconnect().
connect() - место для всего, что обязательно должно выполниться до начала работы: открыть сессию, авторизоваться, проверить, что сервис доступен.
Если connect() упал, приложение не стартует, и вы узнаете об этом сразу, а не на первом запросе.

disconnect() - для уборки: закрыть соединения, разлогиниться, удалить тестовые данные.

class LoginApi(Client):
    async def connect(self) -> None:
        self._session = aiohttp.ClientSession()
        self.token = await self.login()

    async def disconnect(self) -> None:
        await self.logout()
        await self._session.close()


async with DI вызовет connect() в порядке зависимостей, а на выходе disconnect() в обратном, даже если внутри всё упало.

Как использую я?
Поверх nuke_di я написал pytest-плагин, который резолвит клиентов по аннотациям и в рантайме создаёт фикстуры.

Раньше было так:

@pytest.fixture
def client() -> DMApiAccount:
    config = Configuration()
    return DMApiAccount(
        login_api=LoginApi(configuration=config),
        account_api=AccountApi(configuration=config),
    )

async def test_dm_api(client: DMApiAccount) -> None:
    await client.do_smth()

Теперь фикстура не нужна:

async def test_dm_api(client: DMApiAccount) -> None:
    await client.do_smth()

Нужен другой клиент - меняем аннотацию:

async def test_account_api(client: AccountApi) -> None:
    await client.do_account_api_smth()

Никакого лишнего кода, а тот, что есть, типизированный и понятный.

Если каждый клиент dataclass, то наследование тоже работает очень удобно.

Без dataclass пришлось бы так:

class DMApiAccountAuthChild(DMApiAccount):
    def __init__(self, login_api: LoginApi, account_api: AccountApi, auth: AuthApi):
        super().__init__(login_api, account_api)
        self._auth = auth

А с dataclass достаточно так:

@dataclass
class DMApiAccountAuthChild(DMApiAccount):
    _auth: AuthApi

То есть не нужно переопределять конструктор, перечислять все родительские зависимости и вызывать super().__init__(...). Если у DMApiAccount появится новый клиент, наследников трогать не придётся, а это позволяет не перелопачивать весь код.

В общем вот такая вот вам идея. Пользуйтесь)

Привет, напоминаю сегодня крайний день когда можно записаться на тренинги!
https://t.me/AQA_Engineer/518

В прошлом посте я рассказывал про Superpowers:
Набор скиллов, который помогает организовать работу AI-агента: от обсуждения задачи и составления плана до реализации и проверки кода.

Ещё один набор который у меня установлен и которым я пользуюсь это - скиллы от Matt Pocock.

Данный набор представляет из себя фреймворк, который пытается выстроить понятный инженерный процесс, который можно адаптировать под себя.

Из интересного на сайте есть бесплатный курс по использованию скиллов, для того чтобы можно разобраться в подходе подробнее. Естественно после прохождения спамит емейлами с приглашением на большой курс за 100 баксов, но чтобы понять крупными мазками что и когда использовать его достаточно.

Что внутри?

grill-with-docs - агент подробно расспрашивает вас о задаче, помогает выявить неочевидные требования и зафиксировать решения. Вместо того чтобы сразу бросаться писать код, сначала разбираемся, что вообще нужно сделать.

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

to-tickets - разбивает спецификацию на небольшие задачи. Так проще контролировать процесс, проверять результат отдельных этапов и не пытаться реализовать всё за один заход.

implement - помогает реализовывать задачи в рамках подготовленного плана, уделяя внимание тестам и проверке результата.

code-review - отдельный этап проверки изменений. Можно обнаружить ошибки, несоответствия требованиям и проблемы, которые легко пропустить, когда смотришь только на собственную реализацию.

retro - ретроспектива работы. Позволяет разобрать, что получилось хорошо, где агент ошибался и что стоит изменить в следующей сессии.

Есть и другие скиллы для исследования кодовой базы, отладки, рефакторинга и работы с контекстом.

Чем это отличается от Superpowers?
Оба подхода пытаются решить похожую проблему: сделать работу агента более системной и предсказуемой. И где-то скилы для решения одной задачи у них пересекаются.

Но акценты и конкретные workflow отличаются.
Поэтому я бы не стал выбирать что-то одно исключительно по списку возможностей.
Гораздо полезнее посмотреть, как устроены оба набора, и забрать идеи, которые подходят именно вашему процессу.

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

Но если речь о большой фиче, сложном рефакторинге или работе в незнакомой кодовой базе, предварительная проработка требований и нормальная декомпозиция могут сэкономить гораздо больше времени, чем отнимают.

Ну и конечно никакие скиллы (только если они не самописные) не заменят понимания архитектуры проекта и требований к коду. Они помогают организовать процесс, но решения о том, что именно нужно строить и каким должен быть результат, всё равно остаются за человеком.

Где посмотреть?
Репозиторий со скиллами: https://github.com/mattpocock/skills
Бесплатный курс: https://www.aihero.dev/skills

Мне кажется, это хороший вариант для тех, кто уже пользуется агентами, но пока каждый раз выстраивает процесс с нуля.

Следующими постами приложу текст всех обучающих сообщений из его курса, чтобы вам не нужно было регистрироваться и проходить, т.к по сути это просто набор писем))
Но если вам нужен сертификат, который потом высылается можете и зарегистрироваться)