# Async Tests You have already seen how to test your **FastAPI** applications using the provided `TestClient`. Up to now, you have only seen how to write synchronous tests, without using `async` functions. Being able to use asynchronous functions in your tests could be useful, for example, when you're querying your database asynchronously. Imagine you want to test sending requests to your FastAPI application and then verify that your backend successfully wrote the correct data in the database, while using an async database library. Let's look at how we can make that work. ## pytest.mark.anyio If we want to call asynchronous functions in our tests, our test functions have to be asynchronous. AnyIO provides a neat plugin for this, that allows us to specify that some test functions are to be called asynchronously. ## HTTPX Even if your **FastAPI** application uses normal `def` functions instead of `async def`, it is still an `async` application underneath. The `TestClient` does some magic inside to call the asynchronous FastAPI application in your normal `def` test functions, using standard pytest. But that magic doesn't work anymore when we're using it inside asynchronous functions. By running our tests asynchronously, we can no longer use the `TestClient` inside our test functions. The `TestClient` is based on HTTPX, and luckily, we can use it directly to test the API. ## Example For a simple example, let's consider a file structure similar to the one described in [Bigger Applications](../tutorial/bigger-applications.md){.internal-link target=_blank} and [Testing](../tutorial/testing.md){.internal-link target=_blank}: ``` . ├── app │ ├── __init__.py │ ├── main.py │ └── test_main.py ``` The file `main.py` would have: {* ../../docs_src/async_tests/main.py *} The file `test_main.py` would have the tests for `main.py`, it could look like this now: {* ../../docs_src/async_tests/test_main.py *} ## Run it You can run your tests as usual via: