Валерий | AQA Engineer | Автотестирование на Python | REST, gRPC, GraphQL

Всем привет) У меня пара новостей. Я снова включил реакции))) Временно их отключал потому, что нашелся какой-то популярный "засранец" 🤣, который попросил "загавнякать" мне все посты, ну или натравил ботов) По-итогу пришлось включить немного тоталитаризма и реакции сначала закрыть, теперь я их снова включил, но количество подсократил) Вторая новость: Хочу попробовать новый формат публикации постов с кодом. Делать скринами, чтобы было легче читать с телефона. Ставьте - 🔥 если понравилось читать скринами. И ставьте - 👍 если публиковать код текстом. Ниже продублирую как бы смотрелся пост с текстом, чтобы вы понимали как удобнее. ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

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

Преимущества: 1. SRP соблюдён — OrderHelper занимается только логикой работы с заказами. 2. DIP соблюдён — зависит от переданного client, а не от конкретной реализации. 3. Слабая связанность — можно подставить любой client. 4. Тестируемость — легко мокать client. Даже если хочется сделать общий фасад, можно так:

class Facade:
    def __init__(self, db, http, grpc):
        self.db = db
        self.http = http
        self.grpc = grpc

class Order:
    def __init__(self, facade: Facade):
        self.facade = facade

1. Единая точка входа — все зависимости в одном месте. 2. Легко мокать — можно подменить хоть весь facade. 3. Гибкость — можно менять реализацию facade. 4. Контроль — чётко видно, что нужно Order. Возможно, мой код сложнее. • Сложнее локально, но проще глобально. • Попробуйте написать 10 разных тестов для каждого подхода. • Попробуйте заменить clients на другую реализацию. Зачем усложнять простую задачу? Потому, что простая задача завтра станет сложной: • Добавится логирование. • Появятся ретраи. • Метрики. • Кеширование. • Новый клиент. По итогу, что мы имеем: 1. Масштабируемость — подход работает для 1000+ тестов. 2. Поддерживаемость — легко изменять и расширять. 3. Тестируемость — можно тестировать любые сценарии. 4. Переносимость — легко адаптировать под разные фреймворки, менять бэкэнд. 5. Отладка — чётко видно, что происходит, где входная точка и т.д. Я видел разные тренинги и большинство учат работать с той или иной технологией, но почти никто не учить писать так, чтобы фреймворк был поддерживаемым и расширяемым и эту нишу я пытаюсь заполнить.

Лонгрид. Наша платформенная команда старается помочь, как можем, но не нарушая хорошие практики. У нас есть платформенный фреймворк, который может применяться для всего: для ML, разработки, тестов. У него очень крутая концепция и очень крутой интерфейс. Представьте, что вы пишете автотесты, и любой клиент, который вам нужен, можно получить, просто проставив декоратор. Например:

@nuke_test
async def test_something(client: MyClient):
    await client.do_something()

То есть вам даже не нужно писать фикстуру, вы можете сделать любой класс-хелпер. Просто поставить аннотацию, и он будет работать, не надо никаких инстансов — всё работает. Даже если ваш клиент имеет кучу зависимостей типа:

class MyClient(Client):
    api1: Api1
    api2: Api2
    api3: Api3
    ...
    apiN: ApiN

Вам эти зависимости не нужно передавать — тест будет работать так же просто, как в первом примере. Потому что у нашей платформы написан свой DI и определённый механизм, который скрыто для пользователя создаёт все зависимости. Круто? Очень круто. Удобно? Безумно удобно, интерфейс предельно простой. Работает ли это на практике? Не у всех. Почему? Потому что огромные ошибки проектирования тестов, оверинжиниринг, наследование не там, где нужно, нарушение принципов программирования. Сегодня встречался ещё с одной командой, у которых тысячи тестов. Вроде бы вся сложность реализации скрыта, но всё просто капец какое ломучее. И ни один стандартный наш подход не работает. Почему? Например:

from lib import clients

@dataclass
class BaseOrder:
    id: int

class Order(BaseOrder):
    @staticmethod
    def do_something():
        clients.do_something()

def test_order():
    Order(id=1).do_something()

Что здесь не так? 1. Нарушение принципа SRP (Single Responsibility Principle) Почему это плохо: • Order должен представлять бизнес-сущность заказа. • Но он также знает о том, как вызывать внешние сервисы. • Это два разных уровня ответственности. А что если завтра clients.do_something() изменит сигнатуру? Потребует аутентификацию? Появится новый клиент? Вам придётся менять модель Order. Что хорошего? Код простой — да. Но он не расширяемый. Попробуйте написать тест с моком или заменить clients на другую реализацию. 2. Нарушение принципа DIP (Dependency Inversion Principle) from lib import clients — жёсткая зависимость Почему это плохо: • Order зависит от конкретной реализации, а не от абстракции. • Невозможно заменить clients на другую реализацию без изменения Order. • Нарушается принцип «зависеть от абстракций, а не от конкретики». А что если понадобится другой clients для тестов? А если clients переедет в другой модуль? А если нужно будет добавить логирование или метрики вокруг вызовов? 3. Сильная связность Почему это плохо: • Order не может существовать без clients. • clients нельзя заменить или замокать. • Тестирование возможно только с реальным clients. Если clients падает, падают все тесты Order. Сложно тестировать логику Order изолированно. 4. Использование глобальной переменной, которая хранит все объекты. Почему это плохо: • Глобальное состояние может изменяться между тестами. • Сложно контролировать состояние clients. • Побочные эффекты между тестами. Теперь представим, что мы хотим использовать наш подход с декоратором или фикстурой — и не можем. Нам придётся явно передавать зависимости в каждый инстанс Order, что для тысячи тестов очень тяжело. У нас куча входных точек в каждом тесте. Захотим немного поменять clients — есть вероятность разломать кучу тестов, потому что они ультра сильно связаны. Как я считаю, можно было бы сделать правильно: Сделать OrderHelper:

class OrderHelper:
    def __init__(self, client):
        self.client = client

    def make_order(self, id):
        self.client.do_something()

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

Довольно часто можно услышать, что код автотестов должен быть простым, как молоток. Несмотря на то, что язык — это всего лишь инструмент, который помогает ускорить работу тестировщика, и вроде бы можно написать что-то из говна и палок «лишь бы работало», всё-таки лучше думать немного наперёд. Сейчас, работая в платформенной команде, я вижу много кода: приходят ML, разработчики и тестировщики. И да — они пишут рабочий код, но встречаются такие простыни и лапша, в которой тяжело разобраться. При этом есть две крайности: Одни скатываются в оверинжиниринг, другие, наоборот, пишут слишком просто. В обоих случаях код потом сложно поддерживать. Пара рекомендаций. Мы с вами уже смотрели принципы SOLID, и их нужно применять при написании автотестов. Потому что код тестов — это такой же промышленный код, только для другой области, и он должен быть максимально качественным. ✅ 1. Не лепите всё в один класс. Техническая часть для отправки запросов должна быть отдельно, API-клиенты — отдельно, классы-помощники делите по бизнес-доменам. Это позволит меньше лезть в техническую реализацию, а разделение по доменам поможет легче ориентироваться в коде. ✅ 2. Предпочитайте композицию вместо наследования, если это возможно. Внедряйте зависимости — так код будет гибче и проще менять реализацию внутри. ✅ 3. Не упарывайтесь в вынос абсолютно всего повторяющегося кода. Если это сильно усложняет реализацию — лучше пусть в двух классах будет похожий метод, чем вы сделаете супер-абстракцию, которую потом никто не поймёт. ✅ 4. Держите в голове вопрос: «А что будет, если изменится бэкенд?» Сможете ли вы без боли пересадить ваш фреймворк на новый движок? ✅ 5. Опишите правила поддержки фреймворка. Что и где писать, где хранить — единые правила помогают держать код в чистоте. Если подход один, то и автоматизировать конвертацию методов или функций потом проще. ✅ 6. ЕЩЕ РАЗ! Используйте внедрение зависимостей! НЕ ДЕЛАЙТЕ ИНСТАНСЫ нужных классов в коде без острой необходимости, это очень тяжело потом рефачить и тестировать. Используйте фикстуры, это сделает код более прозрачным и понятным. Костыльно написанный код потом приводит к увеличению костылей, потому, что хорошо и быстро его уже не поправить и придется лепить новые костыли, либо все рефакторить. Использование хотя бы этих правил, поможет меньше ныть в случае изменения кор библиотек, и сделает вас в будущем чуть счастливее. ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

Привет! Дошло время поговорить про типы обменников (Exchange) в RabbitMQ 🐰 Зачем вообще это нужно знать? Дело в том, что когда мы подключаемся к обменнику из автотестов нам нужно знать характеристики обменника, и его настройки. Но че хорошо - это то, что python будет рейзить ошибки до тех пор пока мы не настроим подключение к обменнику правильно. Cначала надо рассказать про такое понятие как Routing Key. В RabbitMQ - это строка, которая используется для маршрутизации сообщений от обменника (exchange) к очередям (queues) на основе правил, заданных типом обменника и настройками binding. Простыми словами: - Это как "адрес" или "тег" сообщения, который помогает обменнику решить, в какую очередь его отправить. - Работает в связке с binding (привязкой очереди к обменнику), где указывается, какие routing key очередь принимает. Теперь можно и про обменики. 1. Fanout Публикует сообщения во все очереди, которые связаны с этим обменником через binding. Игнорирует любые настройки binding (routing key или заголовки). Все очереди получат одно и то же сообщение — никаких фильтров. 2. Direct Публикует сообщения только в те очереди, у которых routing key в binding полностью совпадает с routing key сообщения. То есть тут уже появляются строгие правила фильтрации. 3. Topic Похож на Direct, но поддерживает wildcard’ы * и # в routing key. Примеры: • # — означает «все сообщения», фактически как в Fanout. • *.created — сообщения, где routing key заканчивается на .created. Это что-то типа простых регулярных выражений для фильтрации сообщений. 4. Headers Тут вообще не используется routing key. Роутинг идёт по заголовкам сообщений и правилам в binding. В binding настраиваются: • ожидаемые заголовки • параметр x-match: • x-match=any — хотя бы один заголовок должен совпасть • x-match=all — должны совпасть все заголовки В общем, это важно: - чтобы настроить себе тестовую очередь и не своровать сообщения у прода - или если просто хотите «послушать» сообщения из какого-нибудь топика ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

Про Kafka я уже писал. Давайте теперь поговорим про RabbitMQ 🐰 Несмотря на то, что эту тему я буду разбирать на тренинге по брокерам, думаю, остальным тоже будет полезно. Основные понятия, которые нужно знать: • Publisher — публикует сообщения в Rabbit. Если сравнивать с Kafka — это producer. То есть сущность, которая шлёт сообщения в обменник. • Exchange — обменник. Это точка входа всех сообщений в RabbitMQ. Publisher публикует в exchange, а он уже раскидывает сообщения по очередям с помощью routing_key. • Binding — связь между exchange и queue. Через неё мы указываем: какая очередь получает какие сообщения от какого обменника. • Queue — очередь. Здесь лежат сообщения, которые ждут обработки. • Message — сообщение. Атомарная единица данных. • Consumer — подписывается на очередь и получает сообщения от Rabbit. Что важно помнить при тестировании❓ Когда сообщение обработано (т.е. закоммичено), оно пропадает из очереди. И если вы тестируете прямо на боевой очереди, есть риск: • либо “украсть” сообщение у продового консюмера (если закоммитите его раньше) • либо просто не увидеть его, потому что прод его уже съел Что делать ✔️ Создаём свою тестовую очередь и роутим в неё те же сообщения, что и в боевую. Так можно тестировать спокойно, не мешая логике основного приложения. Об этом я подробно расскажу на курсе. Что ещё важно знать❓ Типы обменников. Но это — в следующем посте 😉 ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

Ложное качество кода Сейчас многие начали слишком сильно полагаться на нейросети. Я стал замечать это даже по работам своих студентов. Сегодня можно просто попросить ИИ: Сделай мне проект — и он сгенерирует структуру, классы, папочки, комментарии. На вид — реально как магия. Почти имба. Но если честно, я и сам довольно ленивый. Не раз пытался отрефакторить свой код через нейросети. И пока — ни одной попытки, которую хотелось бы просто взять и влить в мастер. Например, у меня есть библиотека, о которой я уже упоминал — restcodegen. Даже если подробно расписать промт, ИИ начинает генерировать лавину кода — и в какой-то момент даже я уже не понимаю, что и зачем там сделано. Класс на 500-600 строк может разбить на 3-4 файла где в каждом по 500-600 строк!!! Иногда нейросеть скатывается в оверинжиниринг: - Создаёт десятки протоколов и абстрактных классов - Распиливает методы до супер-атомарного состояния - Пишет публичный метод, который вызывает точно такой же приватный — и ты сидишь и думаешь: зачем? Для кого-то это может выглядеть как «код сеньора». Но по факту — это просто усложнение ради усложнения. Настоящий сеньор знает, когда использовать интерфейсы и паттерны, а когда — просто обычную функцию. Тем не менее, ИИ — это очень мощный инструмент. Игнорировать его в 2025 — всё равно что отвергать IDE и писать в блокноте. Но, как и с любой мощной штукой, важно уметь правильно применять. Мои рекомендации по использованию ИИ в разработке: ✅ Решайте задачи атомарно. Каждый шаг — с фиксацией в git. Если пустить нейросеть в код без контроля — она может перелопатить всё, и предыдущие промты окажутся бесполезны. ✅ Формулируйте чёткую задачу. Опишите: — в чём проблема — какой способ решения вам ближе — что должно быть на входе и выходе ✅ Задавайте сигнатуры и контракты. Чем яснее ожидания — тем точнее результат. Описывайте, какие типы, поля, методы хотите видеть. ✅ Показывайте примеры и паттерны, которые хотите использовать. ИИ очень хорошо работает по аналогии — покажите, что вам нравится, и он постарается повторить стиль. ИИ — это очень крутой помощник, который позволяет делать многое, не заглядывая лишний раз в документацию. Но он не заменяет понимание!!! Он усиливает тех, кто и так понимает, что делает. ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

Как вы помните, ранее я проводил опрос о том, какая тема автоматизации тестирования вам была бы интересна. Ну так вот, вы просили — брокеры сообщений, значит, будут брокеры сообщений! Кодовая база уже написана, презентации готовы на 40%. Что будет интересного? Мы будем работать с Kafka и RabbitMQ. Курс будет независим от ступеней Professional и Advanced, это значит, что он будет максимально емким: никаких Allure, настроек CI и прочего — только брокеры сообщений. Если в ступени Professional мы уже работали с асинхронным кодом, то здесь я решил раскрыть еще одну тему — многопоточность. Поэтому рекомендую подтянуть навыки в Python и готовиться к новой ступени! Курс будет помечен маркировкой Professional, потому что темы сложные. В конце мы напишем интеграционный сценарий проверки flow регистрации, почти со всеми промежуточными этапами. Flow можно будет посмотреть на этой UML-диаграмме. В общем, готовьтесь будет интересно! ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

Последнее время моей любимой соцсетью стал LinkedIn. Но, если честно, даже там я чувствую себя не в своей тарелке, потому что он все больше напоминает нельзяграм. Куча постов в стиле: из-за нейросетей нас всех уволят. Потом такая же куча постов: да нихрена эти нейросети без человека не могут. Каждый пост с кричащим заголовком, и все они не про инженерию, а про то, как в два клика нейросеткой сделать какую-нибудь херню или поднять холиварную тему для поднятия охватов. То ли я начинаю стареть, но мне кажется, что технический контент никому особо не нужен и не интересен. Возможно, это и правильно, как говорится, "я сюда деградировать захожу". Примерно такая же ситуация была, когда я вкатывался в IT, в 2018 году. Я начал вести аккаунт про тестирование в запрещенной социальной сети, у меня в подписчиках было три калеки. Я понял, что нельзяграм - это место еды, жоп, сисек и красивой жизни. Но потом вокруг IT набрали такой хайп, что аккаунты начали расти как на дрожжах. Но к тому моменту я уже выгорел в этой теме и ушел писать свои кодики в тележку. Сейчас я всё больше думаю о том, как делать контент, который не только интересен, но и полезен. Хочется писать что-то сложное, чтобы и самому развиваться, и другим помогать. Без хайповых заголовков, без "холиваров ради охватов", а с акцентом на реальную инженерию и глубокие технические темы. Я могу назвать только двух человек, которые себе не изменяют и за которыми слежу очень давно - это Надя и Артем. И один аккаунт, который мне очень нравится, можно сказать, даже немного завидую - это Егор Векслер (его можете очень просто найти). У него и классная подача, и отменный юмор. А что касается моего контента - он не про то, как "в два клика сделать какую-нибудь херню нейросеткой", а про техническое погружение в некоторых случаях даже фундаментальные вещи про которые все чаще забывают. У меня довольно сухая информация и если вы здесь я рад, что вам интересны темы, связанные с инженерией, тестированием, автоматизацией, и техническими подходами. Возможно, именно такие люди и помогут мне вернуть веру в ценность технического контента и профессионального комьюнити)) И да, что думаете насчет дублирования контента в разные соцсети? Стоит ли пробовать технические посты в нельзяграм и линк или это совсем не туда? Ну и поделись, ссылонькой на канал если среди знакомых есть кто пришел в IT не только чтобы зарабатывать 300К\наносек "генерируя код нейросеткой", но и потому что ему реально интересно развиваться в IT-шке. Ну или может просто причина в том, что я пишу неинтересное говно)) ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

В эти выходные у меня первый выпускник с курса Professional 🥳 Естественно, я радуюсь, как и любой преподаватель)

отзыв на курс по API Professional Необычный курс. На нем вы не будете писать автотесты) Курс немного про другое: как выстраивать фреймворк, в котором потом будут писаться тесты . И упростить/ускорить развертывание фреймворка с нуля и его интеграцию в CI Архитектура, полезные либы, линтеры, форматтеры, генераторы кода и подобные вещи. То, что полезно, но приходится собирать из разных мест. Курс сложный, рекомендую закладывать для себя побольше времени. Но однозначно полезный! И делать не на винде 😁 т.к. много работы с путями к файлам, а синтаксис несколько различается. Либо держать это в голове. Ну и на ровном месте вылезают разные какие-то "особенности" винды ) Курс рекомендую, очень полезен 👍

Отзыв Что важно отметить, в курсе действительно собрано очень большое количество информации. И как я уже говорил он больше про SDET , мы и приводим фреймворк автотестов в порядок, используя лучшие практики и разрабатываем библитеку, которая нам эти тесты с нуля поднимает менее чем за минуту. Один раз напилив инструмент, мы забываем про проблемы: - Стандартизации структуры проекта (мы генерируем структуру пакетов проекта) - Поддержки API клиентов в актуальном состоянии (мы генерируем клиенты и встраиваем их в фреймворк) - Настройки пайплайнов (мы пишем common pipeline и интегрируем его в шаблоны проекта) - Написания smoke тестов (мы генерируем код автотестоа) - Поддержка качества кода (мы настраиваем линтеры, пайплайн и прекоммит хуки) и многое другое. Ну, а что касается проблем винды они решаемы, ведь я всегда на связи) ✔️ Я уже открыл запись на следующий поток, который стартует 4 августа. Хотите не просто писать автотесты, а разрабатывать инструменты, перейти на другой уровень профессионализма, сэкономить часы а может даже и недели времени на разработку автотестов себе или вашей компании жду на тренинге) Напомню, вы можете согласовать обучение у вашей компании. У меня уже были ученики из Т-банк, Ингосстрахбанк и других. ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

✨Бесплатный вебинар «Асинхронность в REST API: как тестировать Webhook» ✨ Привет! Я Надежда Дудник, автор канала @protestinginfo, и 15 июня в 16:00 (MSK) приглашаю тебя на бесплатный вебинар по теме, которую важно понимать каждому тестировщику — асинхронные взаимодействия и вебхуки/веб-хуки. 👩‍💻 Кому будет полезно: 🔺 QA-специалистам, которые хотят системно разобраться в принципах работы вебхуков; 🔺 Тем, кто учится тестировать backend и хочет расширить кругозор; 🔺 Тем, кто умеет проверять REST API, но хочет идти дальше; 🔺 Начинающим QA (информация будет доступна для понимания). 👩‍💻 Что будет на вебинаре? 🔺 Поясню, чем отличаются синхронные и асинхронные интеграции; 🔺 Расскажу, как устроены вебхуки и когда их стоит использовать; 🔺 Покажу на примере сайта Vikunja, как настраиваются и вызываются вебхуки при событиях (например, создании задачи); 🔺 На практике протестируем вебхук, отследим и разберём его структуру; 🔺 Поделюсь сервисами, где можно протестировать вебхуки. 👩‍💻 Зачем это нужно: Асинхронные взаимодействия — это фундамент многих современных сервисов. Этот вебинар входит в рамках курса по подготовке на собеседования и закрепления знаний по тестированию ПО. 📒 Когда: 15 июня (воскресенье), 16:00 (MSK) 📍 Где: трансляция в Telegram-канале ProTestingInfo 💬 Формат: практика + объяснения + примера + теория 🔗 Присоединяйтесь к protestinginfo — будет интересно и с пользой для вашей работы и продуктивного обучения! Реклама: Дудник Н.В. ИНН 553902921314 erid: 2Vtzqv9dDgA

Сегодня тестировал библиотеку одного из моих учеников @AndreiDudin с курса Professional. Записал видео - инструмент автоматизирует настройку линтеров, прекоммит-хуков, генерацию проекта и клиентов к сервисам. Это первый ученик на курсе, который дошёл до такого этапа - собрал рабочий инструмент, который реально можно использовать в бою. И если честно мне очень приятно наблюдать за тем как это работает)) Проект позволяет автоматизировать ту самую часть которая занимает самую большую часть времени. И выполняет те вещи, которые обычно приходится делать вручную: ✅ Ставит линтеры и настраивает их по единому стандарту ✅ Настраивает прекоммит-хуки (чтобы не было “залетело в мастер без форматирования”) ✅ Генерирует проектную структуру и клиентов для общения между сервисами Это уже не просто «учебный проект», это прорыв, ближе к SDET и разработке тулов. @AndreiDudin один из тех кто пинал меня с этой ступенью и приобрел курс еще до официального старта. За что ему спасибо. Горжусь и надеюсь, что это только начало — дальше будет ещё круче 💪 ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

🎓 Мою библиотеку выбрали для академического исследования в США На днях мне написал Samuel Flint, исследователь из Университета Небраски–Линкольн (США), с предложением поучаствовать в их научной работе. Они с Dr. Robert Dyer изучают, как разработчики добавляют и убирают аннотации типов в динамических языках, вроде Python. 📌 В рамках исследования они отбирают репозитории, где используются или развиваются практики типизации, и… мой проект pbreflect попал в выборку. Что именно за исследование? Проект называется “Understanding Developers’ Addition and Removal of Type Annotations” (IRB#23988). Они анализируют реальные изменения в open-source-проектах, чтобы понять, зачем и когда программисты используют type hints — и как это влияет на читаемость, сопровождение и качество кода. Исследование одобрено этическим комитетом (IRB), бот TypeChangeBot будет отслеживать изменения, связанные с типами, и приглашать коммитеров поучаствовать в опросе. Подробнее: https://cse-rdyer-05.unl.edu/tcbot Кто они такие? • Dr. Robert Dyer — профессор Computer Science, автор десятков статей по empirical software engineering, участник топовых конференций вроде ICSE и MSR. Примеры: • Understanding Kotlin Type Usage • How developers use Python type annotations • Samuel Flint — его аспирант и соавтор, активно занимается разработкой tooling-а для анализа кода на Python и Kotlin. Почему мне это приятно? Во-первых, моя библиотека попала в поле зрения международных исследователей — а значит, там есть что-то интересное с точки зрения инженерии. Во-вторых, такие штуки — хороший сигнал: когда твой код достаточно читаем, открыт и “type-aware”, чтобы его использовать в научной работе. Ну и, если честно, просто круто, что твой проект не просто валяется на GitHub, а живёт своей жизнью и попадает в научные pdf’ки 😄 ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

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

Так, как я вижу собрались здесь преимущественно любители брокеров сообщений 📱 Ну ок понял, принял ✔️ Буду работать в этом направлении) А пока рекомендую почитать статью про кафку которую я писал несколько месяцев ранее.

У меня всегда был план 🤓 План, какие курсы делать дальше. Что рассказать, разобрать, показать на реальных примерах. Но, как это обычно бывает — времени мало, а хочется всего сразу. Так что… решено: 🎯 Нужна ваша помощь! Что из этого сделать первым? ⸻ 📘 Вот три направления, которые я давно хочу покрыть: 1️⃣ gRPC • что это, зачем • как писать интерцепторы и создавать gRPC клиенты к сервисам. • как работать с микросервисами через gRPC • на что обращать внимание в автотестах 2️⃣ Базы данных • Postgres, Redis, ClickHouse • что это, зачем и как тестировать сервисы которые их используют • Запросы руками, сырые запросы, через SQLAlchemy, генерация схем таблиц. • как писать клиенты для работы с этими БД 3️⃣ Брокеры сообщений • Kafka, RabbitMQ • чем отличаются • как тестировать очереди • как писать клиенты для работы с очередями в автотестах ⸻ 🗳 Голосовалка внизу! Выбирай, что тебе реально нужно. Помоги расставить приоритеты 🙏 А я пойду собирать материал — чтобы было сжато, по делу и с реальными кейсами. 📢 Поделись этим постом с коллегами — пусть тоже выберут. ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы

Последние пару недель — вечер за вечером — пилил инструмент для удобной генерации gRPC-клиентов. Старый гештальт, тянущийся ещё с тех времён, когда я был тестировщиком. Если вы когда-либо пытались тестировать gRPC на Python — вы знаете. 😭 Боль начинается с получения .proto-файлов. 💩 А продолжается клиентами, которые по умолчанию — просто куски говна. Работать с ними максимально неудобно, а местами просто невозможно. Идея зрела больше двух лет. За это время многое изменилось: — нейросети стали помощниками — сам я поднабрался опыта в разработке — и решился вернуться к старой задаче В итоге получилось удобно: 🛠 Можно «выкачивать» протофайлы через reflection_api 🔌 Написал свой плагин и клиент — простой, читаемый, нативный 📦 Минимум рутины и быстрый вкат в тестирование gRPC API на Python А это значит — больше времени на важное: ✔️ тесты ✔️ логика ✔️ прод Сегодня подал заявку на E-CODE — хочу выступить и рассказать, как всё устроено. Примут ли тему — посмотрим. А вот самому процессу — рад. Иногда важно не просто додумать — а доделать. ——————————- 📱 TG-сообщество 📱 Обучение 📱 Отзывы