Where to?

[AlexPHorta]

Where do we go from here? Opened this issue to discuss the road map to use to bring PTBtest to a new version.

[yehuda100]

I guess to match the PTB project at first, and then to start thinking about new features.

[yehuda100]

Also, to make the process of bot testing easy and simple maybe to the level that anything is already configured (all the bot setup stuff) and the user just writes the tests.

[AlexPHorta]

Yeah, I'm doing some reading on PTB first. I was wondering if it's possible/feasible to mock the networking part, so that everything would pass through our implementation. That way, I believe, everything from PTB would be used without a network call. Then, we would write convenience functions/methods to ease the test process.

The idea is that calling something like mockbot.Mockbot() would "trigger" telegram.ext.ApplicationBuilder(). But it will take some time to decipher everything.

One other thing, we maybe could write other convenience methods, in the way that UserGenerator or ChatGenerator work.

[AlexPHorta]

Just funneling everything in here:

#31

[elebur]

I haven't investigated the source code of the PTB very deeply yet only made a quick look through, but here are my thoughts.

• Application is an entry point. It manages all updates via Updater.
• Updater fetches updates for bots from Telegram servers via bot.get_updates
• After an update is received then it is processed by Application.process_update
• process_update loops through all the registered handlers and checks if any matches.
• When the appropriate handler is found Application calls handler.handle_update which in turn calls the callback that is defined by a user, e.g. a callback for the start command

As far as I can see almost all network activity happens in the Bot class, so we have to rewrite all methods of the Bot class.

Then ptbtest patches telegram.ext.Application, replaces the original bot with our Mockbot:

# building the app
application = Application.builder().token("TOKEN").build()
application.add_handler(CommandHandler("start", start))
application.add_handler(CommandHandler("help", help_command))
application.add_handler(MessageHandler(filters.TEXT & ~filters.COMMAND, echo))

mock_app = MockApplication(application)
mock_bot = mock_app.bot

Then we do something like mock_app.send_message("/start") and the mock bot responds.

[AlexPHorta]

Interesting. Yeah, but I was wondering, what is the scope of the tests PTBtest will mock? I mean, would we mock everything, from app creation (with its numerous options for customization) to the most peripheral functions and methods? Or simply the basic functionality?

See, it's possible to run PTB against a Local Bot API Server. So, the needs of heavy users are covered, right? Wouldn't it be better if we focused on the basic functionality and extend it slowly? So, this way, basic users can have a simple solution to testing without running a server.

Or am I getting this wrong?

[yehuda100]

The current implementation is mocking the telegram.bot class so you aren't using the network, the other way is to mock the request class but you'll need to generate a response for every request.

[yehuda100]

I think the end goal should be to cover all the PTB functionality but for now we can start from the basics..

[elebur]

At least we have to mock the Bot class. It has a lot of methods but I agree with you that we could start with the most important ones such as sent_message, sent_audio, sent_video etc.

Also we must think how to implement updates processing. When a user sends something to the bot it receives such messages via requesting get_updates and then Application populates updates_queue and then each update is processed against all registered handlers.

Not 100% sure but I think Application mustn't be mocked at all, the only thing that we must do with it is to replace the original Bot with our Mockbot.

[AlexPHorta]

Or...

We could mock the telegram API, something that could be plugged in place of it, and make convenience methods with the rest.

Like, two parts.

1. The mock API (we could use something like FastAPI or Flak to make it);
2. The rest (convenience methods for the bot, user, chat etc.).

[yehuda100]

you don't need to mock the Application class, you can insert updates one by one with Application.process_update when the automatic updater is None.
Also, PTB has tests for internal use, maybe we can learn from them.

[elebur]

We could mock the telegram API, something that could be plugged in place of it, and make convenience methods with the rest.

@AlexPHorta Wouldn't we eventually end up reinventing the Local Bot API Server?

What would be beneficial in mocking the API over mocking telegram.Bot methods?
Here are a few caveats that I see in the API approach:

1. new entities (FastAPI, Flask) and a web server for the API
2. which in turn leads us to slower tests execution

But while writing this message, I came up with one big benefit - the source code of the telegram.Bot remains the same.

you don't need to mock the Application class, you can insert updates one by one with Application.process_update when the automatic updater is None.

Appliaction calls Updater.start_polling which in turn calls Bot.get_updates

If we decide to mock the telegram.Bot then we could use the approach that the Mockbot already uses - insertUpdates method that puts Update into updates queue.

[AlexPHorta]

Yes, improving from what we already have is really the best approach. Sorry about not responding here today, I was doing some audio work. Going to sleep now and tomorrow we keep on going.

[AlexPHorta]

I'm trying to simplify the message decorator of Mockbot. None of those decorators are being tested. I believe we have to write a boatload of tests to modify this code securely.