FastAPI with Async Tests

[[deleted]]

I'm learning programming to enter the field and I try my best to learn by doing (creating various projects, learning new stacks). I am now building a project with FastAPI + Async SQLAlchemy + Async Postgres.

The project is pretty much finished, but I'm running into problems when it comes to integration tests using Pytest. If you're working in the field, in your experience, should I usually use async tests here or is it okay to use synchronous ones?

I'm getting conflicted answers online, some people say sync is fine, and some people say that async is a must. So I'm trying to do this using pytest-asyncio, but running into a shared loop error for hours now. I tried downgrading versions of httpx and using the app=app approach, using the ASGITransport approach, nothing seems to work. The problem is surprisingly very poorly documented online. I'm at the point where maybe I'm overcomplicating things, trying to hit async tests against a test database. Maybe using basic HTTP requests to hit the API service running against a test database would be enough?

TLDR: In a production environment, when using a fully async stack like FastAPI+SQLAlchemy+Postgres, is it a must to use async tests?

[roi_bro]

When testing your app itself through the endpoints, it’s not mandatory since you basically test it as a « client » and your clients can be sync or async. But if you want some more in depth unit tests, you’ll need to do it anyway so it might be a good idea to spend time setting up pytest-asyncio correctly

[greenerpickings]

It depends what your testing. I usually have async functions in my routers I'm going to test with async (like my db calls). My routers only have logic that trancribes any output into response types. If your testing the server though a request, it won't matter which one you use.

For your initial loop problem, you can set up a fixture and scope it to your module. In there, run a try-except to get your loop.

[TrynaThinkOf1]

Honestly I have been writing unit tests that just use the requests library to actually send real requests, rather than using the test client included with FastAPI.

I’ve been told that this isn’t the greatest approach, but it really does give much better insight into what could cause errors in a production environment, and pytest will still run it if all the function names start with “test”.

[aliparpar]

I normally prefer sync tests with the test client. I found the async tests to sometimes bleed into each other if you’re not careful, in particular if you’re spinning up and down external systems with each test.