Mastering API Testing with FastAPI: Databases, Dependencies, and More!

In this tutorial, I'll guide you through API testing using FastAPI, complete with a full code example. Use this as a template for testing your own APIs!

🎓 Courses:

👍 If you enjoyed this content, give this video a like. If you want to watch more of my upcoming videos, consider subscribing to my channel!

Social channels:

👀 Code reviewers:
- Yoriz
- Ryan Laursen
- Dale Hagglund

🔖 Chapters:
0:00 Intro
0:48 API testing basics
7:24 DB dependency injection
10:47 Setting up the test database
15:03 Write test cases
19:40 Operations layer
24:17 Outro

#arjancodes #softwaredesign #python

DISCLAIMER - The links in this description might be affiliate links. If you purchase a product or service through one of those links, I may receive a small commission. There is no additional charge to you. Thanks for supporting my channel so I can continue to provide you with free content each week!

[nathanbrown]

In terms of other ways to handle database testing:
Rather setup and teardown of the entire database contents each time you run the tests, we have a Docker Image for our test data.
That means we can test against a consistent dataset each time, and easily reset it (i.e. destroy the container) ready for next time (spin up a new container from the image).

This works well for the things like:
- We have a very large schema and set of testing data
- Handles the fact we are still more monolithic than microservices (when/if we can fully split out, we would need separate images for the different services)
- We want to test against specific MySQL versions (i.e. testing against 5.7 with one image and 8.0 with another image)

- Standard Docker benefits of being platform independent, and indeed installation independent (i.e. our server can run the tests on Linux whilst devs can run happily on Windows)

We store the Dockerfile with the schema and initial data in a repository that therefore allows versioning, plus new data can be added as a new file at the end of a list of scripts to be run to setup the data.
Thoughts? Are there any particular weaknesses of this approach? Or better benefits of other methods?

[mikhailu]

It's better not to create items needed just in some tests in the common setup. Every test should be atomic and work with an empty database. So if you need an item for an update test, you should create it within that test

[timbrap]

Would love to see async tests with sqlalchemy

[kt]

Pytest-sqlalchemy-mock creates a "mocked_session" fixture which can be used in tests. Also useful is that mocked tables/records can defined as lists of dicts.

[gweb]

I don't know if it is on purpose or not, but you have been timing your video releases with my Friday lunch breaks and I love it.

[sepehrghafari]

Thank you for the practical videos that can be used in real world work projects. The writing test could not be explained in detail more easily than this.

[oyla]

Very structured and helpful video giving some new aspects I was unsure about how to handle before. Many thanks! :) Was creating a FastAPI Project these days again for a first pitch of a small - specific - control module in a radio station. I was happy not having the need of using a database this time. In the project before (with DB) some it felt kind of unsatisfactory, as I had the feeling of writing some stuff two times (for API and for DB). Also I was not happy about the binding: The will of decoupling was strong in me, but I failed. Can't wait for refactoring this <3

[FransjeFranchise]

Love how you introduced the concepts incrementally. Any plans to cover SQLModel? It plays very nicely with fastapi

[Bubblemaker]

A very good practical guide to testing in python in general, including some comments on integration tests. Thanks!!

[ripichipina]

Nicely done! Short but very solid and specific one. Thank you very much!

[funkenjoyer]

i usually just had some abstract repository that for testing just had an in memory implementation, this seems better since it also checks if you actually work with the db in a way that it works

[andreramalho]

I’m a simple man, Arjan posts a new video, I watch it! Congrats for the good work, Arjan!

[danilshein]

Nice video as always!

And examples are shown is pretty useful as long as your API is such simple one.

In my case almost every API endpoint contains quite complicated business logic over the data that are gathered with several SQL requests that uses some results from previous ones.
All kind of guides I've read about testing an API is always playing around kind of 'hello world' examples.

The second issue for me is that some complex API endpoints requires DB filled with pretty complex set of data. Minimal viable data set is about 6 to 10 GB on disk, besides that it is additional effort to create it from production DB contents and ensure it is consistent.

[unperrier]

Another issue with this approach of using sqlite is database compatibility: I had a similar setup and sqlite did not support ARRAY, which is very common in postgresql.
The solution I came up with is to write a dialect adapter for sqlalchemy that emulates the ARRAY command. But that custom code may have bugs that hide real bugs (false positives) and you don't want to start testing the test framework :)

[jakubstepien]

Exactly the problem I was facing! Thank you, Arjan.

[elliotcossins]

Your videos are amazing, you are an amazing teacher, please never stop making them!

[pramodjingade]

Very useful video! also a simple quiz from a learn tail is a chef’s touch ❤ Thank you!

[devincunningham]

if you have multiple assertions in one test that are not contingent on each other, I would recommend either splitting up the test case (sometimes a bit much) or using a package like pytest_check, which allows pytest to handle multiple checks without ending a test as soon as the first assertion fails. that way, you can get a more detailed report of everything that fails

[leovroy]

Just what I was looking for. Thanks 👍🏻

[agb]

Does pytest auto-recognise the setup and teardown functions? If so does it call them before and after each test, or before and after each test session?