Skip to content

Software Testing

Testing is a fundamental practice in software engineering that ensures code behaves exactly as expected, protecting against regressions as the codebase evolves.

The Testing Pyramid

Testing is generally structured as a pyramid, categorizing tests by their scope and execution cost:

1. Unit Tests (Base of the Pyramid)

  • Scope: Tests a single function, method, or class in complete isolation.
  • Speed: Extremely fast (milliseconds).
  • Volume: Comprises the vast majority of your test suite.
  • Example: Testing that a Pydantic Book model rejects a negative year of publication.

2. Integration Tests (Middle of the Pyramid)

  • Scope: Tests how multiple distinct components interact with one another (e.g., the service layer communicating with the database layer).
  • Speed: Slower than unit tests, as they often require standing up external resources like databases or caches.
  • Volume: Fewer than unit tests, focusing on critical pathways.
  • Example: Testing that the FastAPI /books router successfully calls the database query and returns a JSON response.

3. End-to-End (E2E) Tests (Top of the Pyramid)

  • Scope: Tests the entire system from the user's perspective, mimicking real user behavior across the UI, backend, and database.
  • Speed: Very slow (seconds to minutes).
  • Volume: Used sparingly for the most vital user journeys (e.g., User Login, Checkout process).

Mocking vs. In-Memory Databases

When writing tests that normally interact with a database, you face a decision: do you mock the database, or do you use a real database in memory?

Mocking

Mocking involves replacing the actual database connection object with a "fake" object that intercepts calls and returns hardcoded responses.

  • Pros: Lightning fast. Complete control over edge cases (e.g., forcing a mock to raise a timeout exception).
  • Cons: You aren't testing your actual SQL queries. If your SQL query has a syntax error, the mock will still pass, leading to false confidence.

In-Memory Databases (e.g. SQLite :memory:)

Instead of connecting to a persistent file or a remote PostgreSQL server, the application creates the database tables strictly in the system's RAM.

  • Pros: Real SQL queries are executed. The database enforces real constraints (like Foreign Keys and Unique constraints), ensuring high fidelity.
  • Cons: Slightly slower than pure mocks. Schema syntax might differ from your production database (e.g., SQLite vs PostgreSQL specific functions).

For small to medium projects, using an in-memory SQLite database provides a fantastic balance of speed and reliability without the cognitive overhead of maintaining complex mocks.

Test Isolation and State Pollution

When writing automated tests, one of the most critical principles to follow is Test Isolation.

Test isolation means that every single test function must run completely independently of any other test. A test should not care if it is run first, last, alone, or in parallel with a hundred other tests. If Test A fails or creates a database record, it must have absolutely zero impact on the outcome of Test B.

The Problem: State Pollution

State pollution occurs when tests mutate a shared state (like a database, global variables, or files) and fail to clean up after themselves.

Imagine a test suite for a library application:

  1. test_create_book() creates "The Great Gatsby" in the database.
  2. test_get_all_books() expects there to be exactly 5 default books in the database.

If test_create_book runs first, test_get_all_books will fail because it finds 6 books instead of 5. Worse, if you run the suite twice, test_create_book will crash with an IntegrityError because the primary key for the new book already exists in the persistent database!

This results in Flaky Tests—tests that pass sometimes and fail other times, degrading developer trust in the CI/CD pipeline.

How to Achieve Test Isolation

In Python and FastAPI, we typically use the pytest framework to manage testing. Pytest provides Fixtures, which are functions that run before (and optionally after) your tests.

By using an autouse=True fixture in a central conftest.py file, we can guarantee that before any test function is called, the database is completely wiped clean and reseeded with fresh baseline data.

Coupled with using an in-memory SQLite database (using :memory:), test runs become blazing fast and leave zero trace on your development environment.