Hi, I think it could be done as Mixin class, but still every Storage should be separate class as in original apscheduler. All the storages could be put in one folder.

Spent 3 hours trying parametrize the fixtures, now I hate pytest. It's just not working like that, also would need to mock the mongodb, so basically there's nothing to test as the basic functionality was tested. So sorry, wouldn't do.

P.S. What is IISC?

@Holmes555 IISC = If I see correctly

An example of a parametrized fixture can be seen here:

https://github.com/python-telegram-bot/python-telegram-bot/blob/e432c296a9e76fb7613fcbf25b8ee5f4e1d86497/tests/conftest.py#L273-L278

I'm sure that providing a full-fledged mock of the mongodb is a lot of work and beyond the scope of this PR. however, we only want to ensure that update_job and add_job actually apply the workarounds for PTB, so I'm confident that you can get away with a minimally invasive mock :) Let me emphasize that unit tests should not be viewed as optional and avoidable chore, but are integral for ensuring stability of software and avoiding regressions.

Another note: Both the mongodb and the sqlalchemy jobstores define reconstitue_job by calling supers _restore_job. Is there a specific reason why you called the method PTBStoreAdapter._restore_job instead of directly calling it _reconstitute_job?

Even with fixture parametrize I would need to mock the mongodb, and as I said the workarounds are the same as in PTBSQLAlchemyJobStore, because they both inherit from the PTBStoreAdapter, so it would be double tests.

For the _restore_job I called it like that to differ from the base _reconstitute_job as they are completely different. The same goes to _prepare_job. They shouldn't override base methods.

Even with fixture parametrize I would need to mock the mongodb, and as I said the workarounds are the same as in PTBSQLAlchemyJobStore, because they both inherit from the PTBStoreAdapter, so it would be double tests.

Let me put it that way: Without explicit tests for PTBMongoDBJobStore, a PR could remove the complete body of that class and the CI would still pass. Even if you added unit tests that test PTBStoreAdapter itself, that would still not ensure that PTBMongeDBJobStore actually uses those.
Hence, adding unit tests for PTBMongoDBJobStore significantly reduces the risks of introducing regressions unintentionally.

For the _restore_job I called it like that to differ from the base _reconstitute_job as they are completely different. The same goes to _prepare_job. They shouldn't override base methods.

Ah, I had missed that, thanks!