Я понял. Тут немного по другому, есть библиотека и она к сожалению не поддерживает мок для bot'а! У вас это действительно реализовано лучше. Но имеем что имеем, я использую самую популярную библиотеку для Rust c 3 тысячами звезд.
Можно и нужно каждый хэндлер отдельно покрывать тестами, и это более менее нормально работает. В моем случае я уткнулся в проблему именно E2E теста, от первого сообщения боту до проверки всех возможных сценариев, и в особенности что бот правильно переключается из состояния в состояние.
Хороший вопрос. Мокать bot.send_message напрямую вполне рабочий подход, но я осознанно пошёл в сторону black-box.
Дело вот в чём: чтобы замокать bot.send_message, нужно либо оборачивать бота в трейт, либо городить условную компиляцию. То есть менять прикладной код ради тестов. А я хотел, чтобы бот вообще не знал, что его тестируют. Тестируется ровно тот код, который поедет в прод. Без подмен, без trait-объектов, без #[cfg(test)] в бизнес-логике.
И ровно то, что вы описали («полностью сценарии прогнать, получая ответ и отправляя новые запросы») у меня именно так и работает. Отправил update, проверил ответ, отправил следующий. Полноценный диалог, только вместо Telegram API локальный HTTP-сервер. Бот думает, что общается с Telegram, и ведёт себя соответственно.
Ещё один момент: существующие подходы к тестированию teloxide-ботов (включая teloxide_tests) требовали глубокой связки с внутренностями фреймворка. Тесты получались хрупкими, по сути тестировали не бота, а свои моки. После очередного обновления teloxide половина тестов ломалась не потому что что-то реально сломалось, а потому что внутренний API поменялся.
Я понял. Тут немного по другому, есть библиотека и она к сожалению не поддерживает мок для bot'а! У вас это действительно реализовано лучше. Но имеем что имеем, я использую самую популярную библиотеку для Rust c 3 тысячами звезд.
Можно и нужно каждый хэндлер отдельно покрывать тестами, и это более менее нормально работает. В моем случае я уткнулся в проблему именно E2E теста, от первого сообщения боту до проверки всех возможных сценариев, и в особенности что бот правильно переключается из состояния в состояние.
Хороший вопрос. Мокать
bot.send_messageнапрямую вполне рабочий подход, но я осознанно пошёл в сторону black-box.Дело вот в чём: чтобы замокать
bot.send_message, нужно либо оборачивать бота в трейт, либо городить условную компиляцию. То есть менять прикладной код ради тестов. А я хотел, чтобы бот вообще не знал, что его тестируют. Тестируется ровно тот код, который поедет в прод. Без подмен, без trait-объектов, без#[cfg(test)]в бизнес-логике.И ровно то, что вы описали («полностью сценарии прогнать, получая ответ и отправляя новые запросы») у меня именно так и работает. Отправил update, проверил ответ, отправил следующий. Полноценный диалог, только вместо Telegram API локальный HTTP-сервер. Бот думает, что общается с Telegram, и ведёт себя соответственно.
Ещё один момент: существующие подходы к тестированию teloxide-ботов (включая
teloxide_tests) требовали глубокой связки с внутренностями фреймворка. Тесты получались хрупкими, по сути тестировали не бота, а свои моки. После очередного обновления teloxide половина тестов ломалась не потому что что-то реально сломалось, а потому что внутренний API поменялся.Короче: я мокаю Telegram API, а не код бота.