Async tests not supported

[brendan-morin]

Describe the issue
Async tests (e.g. pytest-asyncio) don't seem to be supported

To Reproduce
A basic example, from a django-ninja app with an async endpoint

@pytest.mark.asyncio
async def test_get(client: TestAsyncClient) -> None:
    brand = baker.make(Brand)
    ...

gives:

django.core.exceptions.SynchronousOnlyOperation: You cannot call this from an async context - use a thread or sync_to_async.

Expected behavior
It would be great to see this just work! Model bakery is possibly one of the best testing utility libraries I've ever used, and almost my exclusive reason to use django. It'd be great to see this work with the async endpoints.

Versions

• Python: 3.12
• Django 5.2.6
• Model Bakery 1.20.5

[brendan-morin]

OK so at least hacking this in turns out to be relatively straightforward, so I think this is maybe fairly solvable. I was experimenting a little just modifying it locally, and can get this syntax working:

brand = await baker.make(Brand)

Then just find/replacing all .save references with .asave in baker.py (and awaiting as needed), adding await ahead of calls to baker.make, and adding async to any function definitions. e.g.

async def make(...):
    ...
    return await baker.make(


async def instance(...)
     if _commit:
            await instance.asave(**_save_kwargs)

A note, intellisense does complain about this: Class 'Brand' does not define '__await__', so the 'await' operator cannot be used on its instances . So there is probably a bit more work to be done in terms of making sure linters/etc are satisfied.

I wasn't thorough or really careful about doing any of this, but I think this demonstrates exposing something like baker.amake for use in async tests would be a viable option. I don't know how much opportunity there is to deconflict code paths between async and sync functions though, so this may also involve a fair bit of duplication, which isn't ideal.

Would love to hear thoughts.

[amureki]

Hey @brendan-morin, thank you for the ticket and for figuring out the nitpicky details!

This is indeed an interesting area, which I, to be quite honest, completely overlooked, as I have almost no touch points with async Django.
Our library is not supporting it, as you correctly noted, because behind the scenes we are using synchronous Django ORM operations.

I see several options:

1. potentially as a workaround to use sync_to_async from asgiref. Given your example it could look like:

from asgiref.sync import sync_to_async
brand = await sync_to_async(baker.make)(Brand)

2. Improve the library to actually have async variants of our public interfaces, for example baker.amake()

I am not sure how much work it is to introduce async helpers and if I can pull something like this any time soon, but this probably will be the way to go.
Maybe we could sketch first drafts (since you already invested some time into it) and see how it works out.

I am sorry for the late reply, it is a bit hard to wrap my head around all kinds of challenges we have here. :)

Cheers,
Rust

[brendan-morin]

as a workaround to use sync_to_async from asgiref

Do you think this is possible to do this under the hood inside baker.make (using async_to_sync instead probably)? I think it's not a bad goal to try to keep the sync/async API the same. asgiref.sync.iscoroutinefunction could potentially be used to identify asynchronous code and route appropriately.

I think having separate versions of the API like amake would be best as a backup plan, since I don't think "truly async" need necessarily be a goal, since non-breaking compatibility would cover essentially all reasonable use cases.

[amureki]

Re: using iscoroutinefunction to auto-detect and route - I'm not sure this would work. If I understand this right, it checks whether a function is async, not whether we're currently executing in an async context. But without some kind of POC, I cannot understand more.
Also, Django themselves are not unifying the APIs, but keeping them separate for a reason, I guess.

Plus, I wonder how this would work with GFK (things I hate the most) - from what I see, Django doesn't have aget_for_model(). Potentially, sync_to_async should work here as a workaround.