How do you test a FastAPI endpoint without real tokens?

WHAT THIS TESTS: This question probes whether you understand FastAPI dependency injection well enough to isolate layers during testing. The interviewer wants to see if you know that business logic tests should not depend on real authentication machinery, and whether you are familiar with FastAPI built-in hooks for swapping dependencies at runtime.

A GOOD ANSWER COVERS: First, mention app.dependency_overrides, which is a dictionary on the FastAPI app instance that maps original dependency callables to replacement callables. Second, explain that you would write a stub function, for example mock_get_current_user returning a hardcoded user model or dict, and assign it in test setup such as app.dependency_overrides[get_current_user] = mock_get_current_user. Third, note that you must clean up after the test, either by deleting the key from the dictionary or by using a pytest fixture with yield that clears overrides afterward, because the override persists on the app object and can leak across tests. Fourth, emphasize that this keeps the test fast and focused on endpoint business logic rather than token cryptography or external identity providers.

COMMON WRONG ANSWERS: A red flag is saying you would generate a real JWT with a secret key and pass it in the header; that couples the test to auth implementation and slows the suite down. Another red flag is manually decoding or validating the token inside the test to extract a user; that misses the point of dependency isolation. Some candidates suggest monkeypatching the Depends class itself, which is overly broad and fragile. Others forget to mention cleanup, implying they have not dealt with override state leaking between tests in practice.

LIKELY FOLLOW-UPS: The interviewer might ask how you would test the auth dependency itself in isolation; the answer is to write separate tests calling the dependency function directly with mocked request objects or headers. They might also ask how to handle nested sub-dependencies; the answer is that overriding a top-level dependency automatically skips its sub-dependencies as well, because FastAPI replaces the entire callable. They could ask about async dependencies; the override can be async or sync, and FastAPI handles it the same way.

ONE CONCRETE EXAMPLE: Suppose you have a dependency get_current_user that reads an Authorization header and validates a Bearer token against an OAuth2 service. In your test file, define def override_get_current_user(): return User(id=1, role='admin'). In a fixture, set app.dependency_overrides[get_current_user] = override_get_current_user. Then use TestClient to POST to the endpoint. The endpoint receives the fake user without any network call or token generation. In teardown, call app.dependency_overrides.clear() or delete the specific key.