Skip to main content
Before proceeding, it’s important to note that running tests against your development database is not ideal. Using your development, staging, or production databases for tests can cause interference and unexpected issues. To mitigate this, we will create and use a completely separate database specifically for testing. Below is an example test for creating a user:
When you run the tests, you might see output similar to the following:
Currently, the application imports the client from the main app. This causes the tests to use the existing development database (typically viewed in PgAdmin). Since the development database might contain pre-existing data, tests can unexpectedly fail. It is best to use a dedicated testing database. Consider this test file snippet that includes the necessary changes to use a separate test database:
The test outputs remain consistent:
One key advantage of our setup is the dependency injection configured in our database.py file. The original database configuration resembles the following:
This configuration creates a session dependency using a function like:
Every SQLAlchemy query in your routes depends on this session object from get_db. To test in isolation, you can override this dependency with one that connects to your dedicated test database. For example, a router file might include database dependency code similar to:
The dependency get_db is injected into the routes, making it easy to override for testing. To point tests to the dedicated database, create an override function (commonly named override_get_db) that returns a session connected to your test database. For example:
This configuration ensures that whenever a route depends on get_db, FastAPI uses the testing session rather than the default development session.
Here’s an example demonstrating the testing of a user creation route using the dependency override:
After setting up the override, your tests run against the dedicated test database, yielding an output similar to:
To complete the test setup, copy your database configuration into your tests and adjust the SQLAlchemy URL to point to your test database. One example is as follows:
Then, define the testing dependency:
Finally, override the dependency in your FastAPI app:
If your test database is new, you might encounter errors due to missing tables. Make sure to create all the necessary tables before running your tests.
One common strategy is to have SQLAlchemy create all tables from your models before the tests execute:
With this setup, the test database (e.g., fastapi_test) is automatically created and populated with the necessary tables when the tests run. You can verify the existence of tables by executing a query like:
After running your test suite, you should see output confirming that tests passed, and you can view the new table entries in your test database via your favorite database tool (such as PgAdmin):
Below is the final summary snippet showing the test database setup:
FastAPI’s dependency override functionality allows you to easily swap out dependencies, such as the database session, during testing. This separation ensures that your tests run in an isolated environment, protecting your development data. Moreover, the test database can be hosted on your local machine, in a Docker container, or on a remote server—simply adjust your connection details accordingly.
The image shows a webpage from the FastAPI documentation, specifically a section on testing a database. It includes a table of contents and instructions for adding tests for an SQL app.
Before running tests against your dedicated testing database (e.g., fastapi_test), make sure that the database exists. In PgAdmin, you can create the database by executing:
If you need to drop or create databases for testing purposes, tools like PgAdmin offer a graphical interface. For example, you might see a confirmation dialog when dropping a database:
The image shows a pgAdmin interface with a confirmation dialog asking if the user wants to drop the database "fastapi_test." The background displays a list of databases and a data output table.
After setting up the test database and overriding the dependency, you can run your tests. A final example of the configuration is as follows:
When you run the tests:
you can verify, using your database tool, that all necessary tables (such as the users table) have been created and populated appropriately. This concludes our guide on setting up a separate test database in FastAPI. By leveraging dependency overrides, you can ensure that tests run in a fully isolated environment without affecting your development data.

Watch Video