I'm curious about the delineation between unit tests and integration tests for FastAPI. Presently I have a FastAPI application deployed on AWS Lambda (containerized deployment allows it to spin up quite fast, even from cold start with big dependencies like numpy and pandas.)
A proxy API Gateway allows methods like './get-student/1' to be passed directly to Lambda, which FastAPI responds to via the library Mangum.
At present, I have integration tests. I send requests to the live url and assert that certain status codes and/or responses are returned using Pytest.
Great! But are unit tests relevant here? Before the Lambda, API Gateway, and DynamoDb integrations, just assessing whether the API methods are "good" (relative, I know) and should be passed to build and deployment pipeline stages.
The unit tests from documentation appear to be integration tests to me- unless I'm mistaken.
Premise
I'm by no ways an expert or experienced in testing, unit testing, integration testing and so on, but from what I've learned and experienced with development, web development and FastAPI in particular, here's my way of testing. Take it with a grain of salt.
Integration tests are great for testing that the entire system behaves correctly (no errors) and as intended (provides the expected output).
Unit tests are specific for testing a particular functionality, which may be exposed or hidden.
If your app is only an api that queries a database and returns the response, then I would say that integration tests are enough. Instead, if there's some logic behind the api (not just the expected parameter is an integer greater than zero), then unit tests should also be included and should test only that particular chunk of code.
Note
I'm a fan of functions, so for me a logic is a separate function that may be shared. For instance, the verification of the VAT code of a company could be a separate function that may be called from several endpoints and thus shared. This function shall be tested with unit tests.