Как удобно тестировать брокеры сообщений?
Многие тестировщики при тестировании брокеров сообщений создают новое соединение перед каждым тестом. Если топиков в интеграционном тестировании несколько, то тесты выполняются очень долго, и каждое сообщение валидируется отдельно и последовательно в тесте.
Как можно улучшить, чтобы переиспользовать соединение и при этом проводить валидацию моментально при наступлении события? При этом делать это расширяемо и удобно.
Мы можем пойти немного в инженерию.
А что если у нас будет один Kafka listener, который будет вычитывать Kafka топики, и несколько подписчиков, которые при получении события (например, сообщения) будут выполнять свою логику?
Так мы с вами реализуем паттерн Observer.
Сначала реализуем Subject или наш KaflaListener, для простоты там будет один метод publish, который и будет уведомлять подписчиков Observer о наступлении событий.
Этот класс так же имеет метод регистрации подписчиков, которых можно сделать очень много.
Дальше опишем интерфейс наших подписчиков.
Теперь описываем конкретные подписчики, где можем сказать что делать при выполнении read_message, например валидацию или перекладывание в очередь.
Теперь мы можем увидеть, что при publish от нашего listener, наше сообщение попадет сразу во все подписчики.
Получим такой результат:
Использовать такую модель можно и в кейсе с обновлением токенов, где подписчиками будут наши клиенты, и по push-модели там будет обновляться авторизация.
Изучение данного паттерна уже включено в курс по брокерам сообщений, который выйдет после Нового года.
А пока вы можете изучить другие паттерны, такие как Proxy, Facade, Decorator, в курсе Advanced.
Многие тестировщики при тестировании брокеров сообщений создают новое соединение перед каждым тестом. Если топиков в интеграционном тестировании несколько, то тесты выполняются очень долго, и каждое сообщение валидируется отдельно и последовательно в тесте.
Как можно улучшить, чтобы переиспользовать соединение и при этом проводить валидацию моментально при наступлении события? При этом делать это расширяемо и удобно.
Мы можем пойти немного в инженерию.
А что если у нас будет один Kafka listener, который будет вычитывать Kafka топики, и несколько подписчиков, которые при получении события (например, сообщения) будут выполнять свою логику?
Так мы с вами реализуем паттерн Observer.
Сначала реализуем Subject или наш KaflaListener, для простоты там будет один метод publish, который и будет уведомлять подписчиков Observer о наступлении событий.
Этот класс так же имеет метод регистрации подписчиков, которых можно сделать очень много.
class KafkaListener:
def __init__(self):
self._clients: list[Subscriber] = []
self._is_running: bool = False
def start(self):
if self._is_running:
raise RuntimeError("already running")
self._is_running = True
def publish(self, message: str) -> None:
for client in self._clients:
client.read_message(message)
def subscribe(self, client: Subscriber) -> None:
if self._is_running:
raise RuntimeError("already running")
self._clients.append(client)
Дальше опишем интерфейс наших подписчиков.
from typing import Protocol
class Subscriber(Protocol):
def read_message(self, message: str) -> None: ...
Теперь описываем конкретные подписчики, где можем сказать что делать при выполнении read_message, например валидацию или перекладывание в очередь.
class FirstClient:
def read_message(self, message: str) -> None:
print(f"Get message from {self.__class__.__name__}, {message}")
class SecondClient:
def read_message(self, message: str) -> None:
print(f"Get message from {self.__class__.__name__}, {message}")
class ThirdClient:
def read_message(self, message: str) -> None:
print(f"Get message from {self.__class__.__name__}, {message}")
Теперь мы можем увидеть, что при publish от нашего listener, наше сообщение попадет сразу во все подписчики.
kafka = KafkaListener()
kafka.subscribe(FirstClient())
kafka.subscribe(SecondClient())
kafka.subscribe(ThirdClient())
for _ in range(10):
kafka.publish(f"message {_}")
time.sleep(2)
Получим такой результат:
Get message from FirstClient, message 0
Get message from SecondClient, message 0
Get message from ThirdClient, message 0
Get message from FirstClient, message 1
Get message from SecondClient, message 1
Get message from ThirdClient, message 1
...
Использовать такую модель можно и в кейсе с обновлением токенов, где подписчиками будут наши клиенты, и по push-модели там будет обновляться авторизация.
Изучение данного паттерна уже включено в курс по брокерам сообщений, который выйдет после Нового года.
А пока вы можете изучить другие паттерны, такие как Proxy, Facade, Decorator, в курсе Advanced.
1🔥8❤3
Хочу поделиться некоторыми слайдами из своего будущего тренинга по брокерам сообщений.
В частности, базовых проблем которые возникают при работе с Kafka в автоматизации тестирования.
А как вы тестируете и какой подход используете?
——————————-
📱 TG-сообщество
📱 Обучение
📱 Отзывы
В частности, базовых проблем которые возникают при работе с Kafka в автоматизации тестирования.
А как вы тестируете и какой подход используете?
——————————-
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥14
Привет, давненько меня не было.
Так вот, хочу рассказать о чем. Пару лет назад у меня возникла идея разработать опенсорс-фреймворк, что-то типа Django или FastAPI. То есть, что-то, что позволит быстро и удобно разработать автотесты. У меня было несколько подходов, и я даже написал такой фреймворк, который уже есть на PyPI, но не скажу, как он называется.)))
Проблема была в том, что я пытался сделать все и сразу, и было тяжело его развивать. Плюс, у меня был богатый опыт в автоматизации, но именно как разработчика опыта было мало. За последние пару лет я многому научился и разобрался. Я решил действовать более итерационно и делать инструменты так, чтобы они были полезны как тестировщикам, так и разработчикам.
Так появились инструменты restcodegen, который по Swagger-спеке генерирует Python-клиенты. Эта библиотека в отрефакторенном виде сейчас присутствует в нашей Python-платформе, и я знаю, что используется некоторыми людьми в проектах за пределами Ozon.
Вторая важная задача заключалась в удобной кодогенерации для gRPC. Подход к генерации gRPC-кода в виде плагина я подсмотрел в нашей же Python-платформе, но чтобы сделать это open source, разработал механизм для получения proto-файлов через gRPC-рефлексию. Теперь, зная хост или IP-адрес, можно легко получить Python-клиент для выбранного gRPC-сервиса.
Так появился инструмент pbreflect, и доклад про него вы можете посмотреть здесь.
Эти инструменты будут полезны любому Python-разработчику веб-приложений.
Теперь настал этап интеграции этих инструментов в сам фреймворк для разработки автотестов. Уже готова часть для работы с REST API. Сколько он экономит времени, зависит от размера вашего API, ведь по одной спецификации генерируются клиенты, тесты и фикстуры. Пользователю остается только заполнить хост своего сервиса, и дальше все, в принципе, работает. Про сам инструмент расскажу позже. Что меня удивило, так это то, что за неделю количество скачиваний составило больше 600. Пока это рекорд из всех моих библиотек. Некоторым подписчикам я уже даже дал потестить, но прошу здесь не спойлерить, об этом расскажу позже!
Так вот, хочу рассказать о чем. Пару лет назад у меня возникла идея разработать опенсорс-фреймворк, что-то типа Django или FastAPI. То есть, что-то, что позволит быстро и удобно разработать автотесты. У меня было несколько подходов, и я даже написал такой фреймворк, который уже есть на PyPI, но не скажу, как он называется.)))
Проблема была в том, что я пытался сделать все и сразу, и было тяжело его развивать. Плюс, у меня был богатый опыт в автоматизации, но именно как разработчика опыта было мало. За последние пару лет я многому научился и разобрался. Я решил действовать более итерационно и делать инструменты так, чтобы они были полезны как тестировщикам, так и разработчикам.
Так появились инструменты restcodegen, который по Swagger-спеке генерирует Python-клиенты. Эта библиотека в отрефакторенном виде сейчас присутствует в нашей Python-платформе, и я знаю, что используется некоторыми людьми в проектах за пределами Ozon.
Вторая важная задача заключалась в удобной кодогенерации для gRPC. Подход к генерации gRPC-кода в виде плагина я подсмотрел в нашей же Python-платформе, но чтобы сделать это open source, разработал механизм для получения proto-файлов через gRPC-рефлексию. Теперь, зная хост или IP-адрес, можно легко получить Python-клиент для выбранного gRPC-сервиса.
Так появился инструмент pbreflect, и доклад про него вы можете посмотреть здесь.
Эти инструменты будут полезны любому Python-разработчику веб-приложений.
Теперь настал этап интеграции этих инструментов в сам фреймворк для разработки автотестов. Уже готова часть для работы с REST API. Сколько он экономит времени, зависит от размера вашего API, ведь по одной спецификации генерируются клиенты, тесты и фикстуры. Пользователю остается только заполнить хост своего сервиса, и дальше все, в принципе, работает. Про сам инструмент расскажу позже. Что меня удивило, так это то, что за неделю количество скачиваний составило больше 600. Пока это рекорд из всех моих библиотек. Некоторым подписчикам я уже даже дал потестить, но прошу здесь не спойлерить, об этом расскажу позже!
🔥12👍5❤2
Привет!
Как и обещал - зарелизнул первую итерацию своего фреймворка для генерации автотестов.
Что он уже умеет?
Берёшь свою swagger/openapi спеку, одна команда и у тебя готов:
- проект с клиентами
- фикстурами
- тестами
- конфигами.
Без нейросетей, чистый, детерминированный результат.
По факту:
• создает проектную структуру
• пишет фикстуры
• пишет тесты
• пишет конфигурацию
• и всё это одной командой
Погонять можно уже сейчас, фреймворк рабочий.
А как им пользоваться - скоро запишу занятие в ступень Профешнл.
С момента релиза - почти 1000 скачиваний, практически без рекламы.
Если не заброшу (а я вроде не собираюсь) - кто знает, может когда-нибудь станет таким же популярным, как FastAPI. А чего нет?)
Следующая итерация: gRPC + Postgres.
Посмотреть пример проекта, который генерится одной командой - вот тут, достаточно только указать URL сервиса и всё взлетает🔥
Как и обещал - зарелизнул первую итерацию своего фреймворка для генерации автотестов.
Что он уже умеет?
Берёшь свою swagger/openapi спеку, одна команда и у тебя готов:
- проект с клиентами
- фикстурами
- тестами
- конфигами.
Без нейросетей, чистый, детерминированный результат.
По факту:
• создает проектную структуру
• пишет фикстуры
• пишет тесты
• пишет конфигурацию
• и всё это одной командой
Погонять можно уже сейчас, фреймворк рабочий.
А как им пользоваться - скоро запишу занятие в ступень Профешнл.
С момента релиза - почти 1000 скачиваний, практически без рекламы.
Если не заброшу (а я вроде не собираюсь) - кто знает, может когда-нибудь станет таким же популярным, как FastAPI. А чего нет?)
Следующая итерация: gRPC + Postgres.
Посмотреть пример проекта, который генерится одной командой - вот тут, достаточно только указать URL сервиса и всё взлетает
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - ValeriyMenshikov/e2efast: E2E Lib
E2E Lib. Contribute to ValeriyMenshikov/e2efast development by creating an account on GitHub.
🔥15👍9
Привет ребят, сегодня такой завал, хотелось подвести какие-то итоги, но наверное уже не успею)
По поводу чего спросите вы?
Сегодня у меня День Рождения)
И вы уже сделали мне подарок, наконец-то набралось 1400 человек, ну если хотите еще меня порадовать поделитесь ссылочкой на мой канал со своими коллегами.
А я и дальше смогу делиться с вами хорошим техническим контентом и классными тренингами)
Спасибо что в этот день вы со мной)
По поводу чего спросите вы?
Сегодня у меня День Рождения)
И вы уже сделали мне подарок, наконец-то набралось 1400 человек, ну если хотите еще меня порадовать поделитесь ссылочкой на мой канал со своими коллегами.
А я и дальше смогу делиться с вами хорошим техническим контентом и классными тренингами)
Спасибо что в этот день вы со мной)
1🔥37❤5
Всем привет! У кого, как и у меня, работы под конец года подвалило
Я тут с подарочками)
Во-первых, я закончил записывать курс по тестированию брокеров сообщений✍️ .
Знаю, многие ждали - видео полностью готовы (самая сложная часть позади). Осталось залить на платформу и наваять лендинг.
Так же хочу напомнить про свой опенсорс restcodegen.
В последней обнове я выпилил лишние зависимости, переехал на другой парсер, так что пакет стал легче и теперь будет меньше конфликтов.
pbreflect - пофиксил баги, которые были связаны с использованием annotation.proto, и библиотека стала стабильнее.
Выпустил новый релиз e2efast - теперь фикстуры резолвятся автоматически и без багов (по крайней мере пока).
Планирую добавить, чтобы в конфиг автоматически проливался хост, а не руками заполнять.
Но для этого надо поправить парсер в restcodegen, поэтому пока всё по-старинке — хост руками.
Напомню:
• restcodegen - библиотека для генерации клиента к REST API по спецификации OpenAPI 3
• pbreflect - библиотека для получения протофайлов по URL с использованием gRPC-рефлексии и генерации клиентов
• e2efast - фреймворк для быстрого развертывания каркаса автотестов для REST-сервисов (генерация клиентов, фикстур, тестов)
В общем: пользуемся, говорим спасибо 😎 и ждём открытия продаж курса по брокерам!
——————————-
📱 TG-сообщество
📱 Обучение
📱 Отзывы
Я тут с подарочками)
Во-первых, я закончил записывать курс по тестированию брокеров сообщений
Знаю, многие ждали - видео полностью готовы (самая сложная часть позади). Осталось залить на платформу и наваять лендинг.
Так же хочу напомнить про свой опенсорс restcodegen.
В последней обнове я выпилил лишние зависимости, переехал на другой парсер, так что пакет стал легче и теперь будет меньше конфликтов.
pbreflect - пофиксил баги, которые были связаны с использованием annotation.proto, и библиотека стала стабильнее.
Выпустил новый релиз e2efast - теперь фикстуры резолвятся автоматически и без багов (по крайней мере пока).
Планирую добавить, чтобы в конфиг автоматически проливался хост, а не руками заполнять.
Но для этого надо поправить парсер в restcodegen, поэтому пока всё по-старинке — хост руками.
Напомню:
• restcodegen - библиотека для генерации клиента к REST API по спецификации OpenAPI 3
• pbreflect - библиотека для получения протофайлов по URL с использованием gRPC-рефлексии и генерации клиентов
• e2efast - фреймворк для быстрого развертывания каркаса автотестов для REST-сервисов (генерация клиентов, фикстур, тестов)
В общем: пользуемся, говорим спасибо 😎 и ждём открытия продаж курса по брокерам!
——————————-
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21❤3👨💻1
Forwarded from Иван Пономарев
Отзыв на тренинг "REST API Test Automation (Advanced)" от Валерия Меньшикова
Начну с того, что на всеразличных онлайн курсах по автоматизации тестирования (вполне себе хороших и не очень) я уже "собаку сЪел", поэтому есть с чем сравнить. Все эти курсы объединяет одно: упор сделан на web-автоматизацию на selenium с применением паттерна PageObject, а REST API уделяется совсем немного внимания (1, максимум 2 урока), хотя, казалось бы, API идеально подходит для автоматизации в первую очередь. Поэтому искал именно курс, на котором покажут и расскажут как можно выстроить структуру проекта по автоматизации именно API, и каким-то чудом наткнулся на этот тренинг от Валерия Меньшикова.
На тренинг лучше идти с уверенным знанием синтаксиса языка python, пониманием структур данных языка, циклов, ветвлений и базовым представлением об ООП. Хоть на курсе и есть занятие по основам python (знаю, что Валерий добавил его по просьбам учащихся), но всё же лучше изучить их где-нибудь на других платформах.
По сути курс начинается с написания автотеста, который после 1-го занятия представляет длинную простыню трудно читаемого кода (чего???).
Но потом начинается самое интересное: мы начинаем изучать всеразличные паттерны пректирования, такие как proxy, facade, decorator, начинаем применять различные инструменты для конфигурирования проекта, валидации запросов и ответов, проверок и много чего еще. В результате эта "длинная простыня трудно читаемого кода" превращается в легко поддерживаемый фреймворк, а сами тесты становятся читаемыми и понятными. Одного взгляда на автотест хватит, чтобы понять что там происходит и что проверяется.
Валерий учит не просто писать автотесты, а делать это так, чтобы в случае чего можно было быстро внести какие-то изменения, и всё продолжит работать. При этом всём так же прокачиваются навыки разработки в целом.
Ну и вишенкой на торте является прикручивание понятного и читаемого allure-отчета, отчета о покрытии приложения тестами, настройка CI в GitHub Actions и GitLab CI с нотификацией результатов тестирования в канал телеграм через бота.
Тренинг действительно можно назвать "уникальным", ибо навряд ли где-то можно найти что-то подобное.
От меня 10 из 10 и большое спасибо Валерию за то, что делится такими бесценными знаниями.
Начну с того, что на всеразличных онлайн курсах по автоматизации тестирования (вполне себе хороших и не очень) я уже "собаку сЪел", поэтому есть с чем сравнить. Все эти курсы объединяет одно: упор сделан на web-автоматизацию на selenium с применением паттерна PageObject, а REST API уделяется совсем немного внимания (1, максимум 2 урока), хотя, казалось бы, API идеально подходит для автоматизации в первую очередь. Поэтому искал именно курс, на котором покажут и расскажут как можно выстроить структуру проекта по автоматизации именно API, и каким-то чудом наткнулся на этот тренинг от Валерия Меньшикова.
На тренинг лучше идти с уверенным знанием синтаксиса языка python, пониманием структур данных языка, циклов, ветвлений и базовым представлением об ООП. Хоть на курсе и есть занятие по основам python (знаю, что Валерий добавил его по просьбам учащихся), но всё же лучше изучить их где-нибудь на других платформах.
По сути курс начинается с написания автотеста, который после 1-го занятия представляет длинную простыню трудно читаемого кода (чего???).
Но потом начинается самое интересное: мы начинаем изучать всеразличные паттерны пректирования, такие как proxy, facade, decorator, начинаем применять различные инструменты для конфигурирования проекта, валидации запросов и ответов, проверок и много чего еще. В результате эта "длинная простыня трудно читаемого кода" превращается в легко поддерживаемый фреймворк, а сами тесты становятся читаемыми и понятными. Одного взгляда на автотест хватит, чтобы понять что там происходит и что проверяется.
Валерий учит не просто писать автотесты, а делать это так, чтобы в случае чего можно было быстро внести какие-то изменения, и всё продолжит работать. При этом всём так же прокачиваются навыки разработки в целом.
Ну и вишенкой на торте является прикручивание понятного и читаемого allure-отчета, отчета о покрытии приложения тестами, настройка CI в GitHub Actions и GitLab CI с нотификацией результатов тестирования в канал телеграм через бота.
Тренинг действительно можно назвать "уникальным", ибо навряд ли где-то можно найти что-то подобное.
От меня 10 из 10 и большое спасибо Валерию за то, что делится такими бесценными знаниями.
❤10
Недавно в линке увидел пост, где коллега искал человека или школу которые смогут обучить команду НЕ начинающих автоматизаторов, а людей с опытом.
На самом деле его запрос был необычный. Там были и базовые вещи, но из того, что мне показалось интересным в его запросе это "Абстрактные классы", "Интерфейсы", "Алгоритмы", "Эффективное использование многопоточности", на python.
Не могу говорить за тенденцию, но немного повангую, а может пофантазирую.
В связи с активным использованием ИИ, просто написать рабочий код уже не является преимуществом в профессии или каким то чудом, это делается как раз легко.
Так что этап когда сотрудник, не просто пишет рабочий код, а понимает как писать хороший код, понимает хорошие практики и может валидировать ИИ вполне себе вписывается в эту модель развития.
Можно ли без этих знаний писать автотесты? В 90% случаев да и довольно неплохие.
Могу предлположить, что скоро, да и уже от многих AQA просят писать QА сервисы, разрабатывать свои инструменты автоматизации. И вот как раз сюда требуемые знания ложатся прекрасно.
Что касается меня, я конечно предложил свои программы для его команды, там пусть сами думают) Но отдельно тренинг под его команду я разрабатывать не буду, мне лень, да и тем более у меня уже есть рабочий материал.
Ведь изначально идея моих тренингов была такая, что я хотел давать такие темы, которые обычно в курсах по автоматизации не рассматриваются и которых капец как не хватато мне, когда я рос как автоматизатор. Многие вещи я набивал только практикой, а многие знания до сих пор можно узнать только из (представьте себе) книг, не потому что их не знает чат гпт, а потому, что человек который работает с ИИ не знает, что спросить, а в книгах все идет структурировано и по порядку, и тренингов по сложным темам и с хорошей подачей днем с огнем не сыскать.
Я всегда упарывался над архитектурой тестов, поэтому у меня много посвящается внимания этим темам. Темы асинхронки и многопоточности так же присутствуют в моих тренингах в привязке для решения конкретных задач.
Наверное закономерно, но это привело меня в разработку, да еще и в команду python платформы, чем я безумно горжусь)
Команда которая так же как и я упарывается над архитектурой и от которой я очень многому научился.
К чему я это все, к тому что наверное я очень хочу выдавать желаемое за действительное, и чтобы количество написанного кода перерастало в качество)
Чтобы автоматизаторы развивались и чтобы моя светлая идея выращивать топовых инженеров развивалась.
На самом деле его запрос был необычный. Там были и базовые вещи, но из того, что мне показалось интересным в его запросе это "Абстрактные классы", "Интерфейсы", "Алгоритмы", "Эффективное использование многопоточности", на python.
Не могу говорить за тенденцию, но немного повангую, а может пофантазирую.
В связи с активным использованием ИИ, просто написать рабочий код уже не является преимуществом в профессии или каким то чудом, это делается как раз легко.
Так что этап когда сотрудник, не просто пишет рабочий код, а понимает как писать хороший код, понимает хорошие практики и может валидировать ИИ вполне себе вписывается в эту модель развития.
Можно ли без этих знаний писать автотесты? В 90% случаев да и довольно неплохие.
Могу предлположить, что скоро, да и уже от многих AQA просят писать QА сервисы, разрабатывать свои инструменты автоматизации. И вот как раз сюда требуемые знания ложатся прекрасно.
Что касается меня, я конечно предложил свои программы для его команды, там пусть сами думают) Но отдельно тренинг под его команду я разрабатывать не буду, мне лень, да и тем более у меня уже есть рабочий материал.
Ведь изначально идея моих тренингов была такая, что я хотел давать такие темы, которые обычно в курсах по автоматизации не рассматриваются и которых капец как не хватато мне, когда я рос как автоматизатор. Многие вещи я набивал только практикой, а многие знания до сих пор можно узнать только из (представьте себе) книг, не потому что их не знает чат гпт, а потому, что человек который работает с ИИ не знает, что спросить, а в книгах все идет структурировано и по порядку, и тренингов по сложным темам и с хорошей подачей днем с огнем не сыскать.
Я всегда упарывался над архитектурой тестов, поэтому у меня много посвящается внимания этим темам. Темы асинхронки и многопоточности так же присутствуют в моих тренингах в привязке для решения конкретных задач.
Наверное закономерно, но это привело меня в разработку, да еще и в команду python платформы, чем я безумно горжусь)
Команда которая так же как и я упарывается над архитектурой и от которой я очень многому научился.
К чему я это все, к тому что наверное я очень хочу выдавать желаемое за действительное, и чтобы количество написанного кода перерастало в качество)
Чтобы автоматизаторы развивались и чтобы моя светлая идея выращивать топовых инженеров развивалась.
🔥17👍8❤4
Forwarded from Ozon Tech
gRPC традиционно вызывает панические атаки.
А если говорить про тестирование на Python, слабонервных лучше убрать от экранов. Но если вы хотите узнать, как просто генерировать клиентов и создавать собственные плагины для protoc, усаживайтесь поудобнее. Мы подготовили карточки⬆️
Для тех, кто хочет полного погружения, предлагаем доклад⬅️ старшего разработчика нашей Python-платформы и автора библиотеки PBReflect ⬅️ Валерия Меньшикова.
#ozontech_experts #python
А если говорить про тестирование на Python, слабонервных лучше убрать от экранов. Но если вы хотите узнать, как просто генерировать клиентов и создавать собственные плагины для protoc, усаживайтесь поудобнее. Мы подготовили карточки
Для тех, кто хочет полного погружения, предлагаем доклад
#ozontech_experts #python
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥10
Forwarded from Ozon Tech
Ставьте
P. S. И кстати, с Днём компьютерщика!
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
😁10❤1