Python Friday #234: Database Tests for the FastAPI Application

Last week we moved from an in-memory data store to SQLAlchemy and persist our tasks inside an SQLite database. We have two things we need to optimize, or else we end up with problems along the way.

This post is part of my journey to learn Python. You find the code for this post in my PythonFriday repository on GitHub.

 

The two problems

Our current implementation has two notable problems:

  1. The tests in test_data_store_db.py write to test_db.sqlite, while those in test_todo.py write to todo_api.sqlite. That can be a problem if the databases differ, and we may accidentally clutter our development database.
  2. The database(s) will grow with every test run. It may take a long time, but eventually the small entries accumulate and fill our disk.

Let us address the problem with the two databases first, then with a solution for that our second problem is a lot simpler to solve.

 

Change the get_db() dependency in the endpoints for the tests

The todo_api.sqlite filename comes from our get_db() method in the router. Since we inject the get_db() method into our endpoints as a dependency, we can use the built-in approach of FastAPI to replace dependencies for testing.

In our test, we implement our own get_db() method with the right database file and tell FastAPI to replace the dependency for our tests:

ATTENTION: The method name for the key in dependency_overrides does not have ‘ ‘ around. If you put them there, the dependency cannot be found and will not be replaced!

 

Cleanup before the test run

We can clean up the database before or after the test run. The first hunch may be to clean-up after, but that means if something goes wrong, we may no longer have the data to understand the problem. A better approach is to clean up before the test run.

We can define a scope in our with_db() fixture so that it runs only once for the whole test suite. That allows us to delete the old test database (should the file exist) before we run the tests:

To make sure that the cleanup does not happen in the middle of our test run, we need to use that fixture everywhere where we use the database. We can extend our endpoint tests to use our fixture:

While this can be done, it is somewhat cumbersome, and we may forget it when we write tests in the future. Let us remove the fixture from the tests we do not need and remove the part that deletes the database file:

 

Startup hook

Pytest lets us use hooks at specific places in the test run. One of the earliest we can use is pytest_sessionstart() that runs after the session object is created, but before the tests are collected.

To use this hook, we create a conftest.py file in the top folder of our project and add this code:

Whenever we now run Pytest, the hook runs and if we have an existing test database, it will remove it:

Our test output shows that the hook did run as one of the first things.

 

Next

The dependency overwrites and the scope for the test fixture can help us to improve our integration tests. We now only need one database for our tests and every test run starts with a clean, new database.

Next week we integrate Alembic to our application so that we can migrate the database should we need more fields on our entities.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.