Боевой тест Telegram-бота: когда теория встречается с реальностью

Проверяем Telegram-бота в боевых условиях: тестируем управление доступом

Когда создаёшь бота для Telegram, одно дело — писать тесты в PyTest, и совсем другое — убедиться, что он работает с реальными аккаунтами и обрабатывает команды так, как задумано. Вот я и пришёл к моменту, когда нужно было залезть в грязь и провести самый важный тест: запустить бота и написать ему сообщение из Telegram.

Задача была простая, но критичная

Я добавил в бота новую фишку — управление доступом через команды /manage. Идея: в групповом чате владелец может сделать его приватным (/manage add), и тогда бот будет отвечать только ему. Затем команда /manage remove открывает доступ для всех обратно. Плюс ещё /recall и /remember для сохранения данных в памяти чата.

Звучит просто, но нужно убедиться, что: - бот действительно игнорирует сообщения посторонних в приватном режиме; - владелец всегда может управлять ботом; - после отключения приватности всё работает как раньше.

Как я это проверял

Сначала поднял бота локально:

python telegram_main.py

Затем начались «полевые испытания»:

1. Первый скрин-тест — написал боту /manage add из своего аккаунта. Бот должен был записать ID чата в таблицу БД managed_chats и включить режим приватности. Отправил обычное сообщение — бот ответил. ✅

2. Второй аккаунт — попросил друга отправить то же сообщение из другого Telegram. Бот молчал, хотя обычно отвечает на всё. Middleware permission_check.py срабатывал корректно и блокировал обработку. ✅

3. Финальный тест — написал /manage remove и снова попросил друга отправить сообщение. На этот раз бот ответил. Приватность снята, всё доступно. ✅

Что оказалось неочевидным

Интеграционное тестирование в Telegram выявило одну тонкость: когда ты работаешь с асинхронным обработчиком команд в aiogram, timing-зависимые проверки могут создавать гонки условий. У меня был момент, когда команда /manage add срабатывала, но middleware проверял доступ до того, как запись попала в БД. Пришлось добавить небольшой await после insert’а, чтобы гарантировать консистентность.

Ещё обнаружил: если ты работаешь с SQLite и одновременно несколько обработчиков пишут в таблицу, нужен явный commit() или использовать контекстный менеджер транзакций. Иначе другой процесс не увидит изменения до commit’а.

Что дальше?

После успешных интеграционных тестов я задокументировал всё в README.md — добавил секцию про управление доступом с примерами команд. Создал отдельный файл docs/CHAT_MANAGEMENT.md с полной архитектурой ChatManager, схемой БД и API reference для всех методов класса.

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

Главный вывод: прежде чем гордиться unit-тестами, обязательно проверь свой код в реальной среде. Иногда именно там появляются неожиданные проблемы, которые не поймать никаким PyTest.

😄 Что общего у Telegram API и инструкций по использованию телефона? И то, и другое люди игнорируют в пользу метода проб и ошибок.