Explain FastAPI dependency overrides with an in-memory SQLite test example

WHAT THIS TESTS: This question probes whether you understand FastAPI's first-class testing affordances and can separate test infrastructure from production code. The interviewer wants to see that you know how to swap out a real database dependency for a test double without rewriting endpoints or resorting to brittle monkey-patching.

A GOOD ANSWER COVERS: First, state that FastAPI exposes an app.dependency_overrides dictionary that maps a dependency callable to a replacement callable. Second, explain that the replacement should match the original signature and return type so path operations receive the same interface, typically a SQLAlchemy Session. Third, describe lifecycle management: the override function should create the in-memory engine, run create_all, yield a session, and then rollback or drop tables afterward so tests remain isolated. Fourth, mention that overrides are usually applied in a pytest fixture or test setup block and cleared in teardown, often by resetting the dictionary or using a context manager pattern.

COMMON WRONG ANSWERS: A major red flag is suggesting monkey-patching the module where the dependency is defined or mutating a global session variable. Another weak pattern is mocking the ORM query methods directly instead of replacing the dependency, because that couples tests to implementation details. Finally, proposing to branch inside the dependency with an if testing flag shows a lack of separation of concerns and can leak test state into production.

LIKELY FOLLOW-UPS: The interviewer may ask how you would handle dependencies with yield and cleanup code, or how to override nested sub-dependencies. They might also ask about scoping: whether the override affects only one test or the whole app instance, and how to avoid cross-test pollution when running tests in parallel.

ONE CONCRETE EXAMPLE: Suppose you have a get_db dependency that yields a SessionLocal from a production PostgreSQL engine. In your conftest.py, you define an override_get_db function that creates a new SQLAlchemy engine using sqlite:///:memory:, runs Base.metadata.create_all(bind=engine), yields a session from sessionmaker bound to that engine, and then closes the session and drops metadata after the yield. You then assign app.dependency_overrides[get_db] = override_get_db inside an autouse fixture. Your tests now hit an isolated in-memory database while your route code stays unchanged.