Talk is cheap, show me the code.

When creating business end-to-end tests, we must focus on properly preparing the test environment. This ensures we can write tests in just a few lines and concentrate on developing business value. For this reason, we'll start with the testing library. In Python, I recommend pytest, and this article is based on its implementation. However, you can choose any library that allows you to:

• Set dependencies between tests (execution order)
• Mock database persistence between tests
• Easily test endpoints, including a client for API testing

Example of a business end-to-end test

Let’s use an example of a business end-to-end test. Suppose we want to check whether the user path to purchase a subscription without logging in works. This requires us to have a user who hits the endpoint.

@pytest.mark.usefixtures("use_persistent_db")
@pytest.mark.asyncio
async def test_start_subscription_checkout_session_as_anonymous_user(request, mocker, shared_data,
                                                                     anonymous_user_for_testing_subscription):
    pricing_id = shared_data.get("pricing_for_purchase_subscription")

    response = await anonymous_user_for_testing_subscription.post("/api/subscription/checkout", data={
        "pricing_id": pricing_id})
    response.is_success()
    redirect_url = response.key_value("redirect_url")

Here’s a simple test that checks if my application allows redirecting an anonymous user to the payment system. It’s just a few lines, yet I can be confident the process works, regardless of changes to my software.

Persistent Database Through All Tests

A persistent database is essential. Since we’re writing business tests, dividing functionality into stages, we need to ensure data created on the server in one test is available for the next. For Django, which we’re focusing on today, the database is defined in the settings. The first step is to create a fixture that specifies the database settings:

@pytest.fixture(scope="session")
def django_db_setup():
    """
    Configures the default Django database settings to use an in-memory SQLite database
    for efficient testing. Overrides the default database configuration with specific
    options for connection handling and timezone.

    This fixture runs once per test session.
    """
    settings.DATABASES["default"] = {
        "ENGINE": "django.db.backends.sqlite3",
        "NAME": ":memory:",
        "ATOMIC_REQUESTS": False,
        "TIME_ZONE": "America/Chicago",
        "CONN_HEALTH_CHECKS": True,
        "CONN_MAX_AGE": 0,
        "OPTIONS": {},
        "AUTOCOMMIT": True
    }

This creates an in-memory SQLite database. For testing asynchronous functions, we must enable Autocommit. Next, we can set up a persistent database for all tests using setup_persistent_db:

@pytest.fixture(scope="session")
def setup_persistent_db(django_db_setup, django_db_blocker):
    """
    Sets up a persistent test database using the SQLite in-memory database for the session.
    This fixture creates a test database and keeps it across tests, allowing test functions
    to share data within a single session.

    After the session, the database is destroyed.

    :param django_db_setup: Sets up the initial database configuration.
    :param django_db_blocker: Provides access to manage the database creation and teardown.
    """
    with django_db_blocker.unblock():
        connections["default"].creation.create_test_db(keepdb=True)
    yield
    with django_db_blocker.unblock():
        connections["default"].creation.destroy_test_db(":memory:")

This fixture creates an in-memory database and keeps it alive for the entire pytest session.

The final step is creating a fixture that allows us to use the database only for necessary tests. This is done with the use_persistent_db fixture:

@pytest.fixture(scope="function")
def use_persistent_db(setup_persistent_db, django_db_blocker):
    """
    Provides access to the persistent database within individual test functions.
    This fixture ensures that each test function can connect to the database set up
    by `setup_persistent_db`.

    :param setup_persistent_db: Ensures the database is set up for the session.
    :param django_db_blocker: Allows test functions to unblock database access.
    """
    with django_db_blocker.unblock():
        yield

Its scope is set to function—this means you can also write tests that won’t cause database writes.

With this setup, running your tests ensures persistent data between tests for all tests using the use_persistent_db fixture.

Container for Data Between Tests

To simplify the process, I prefer using my abstraction, SharedData:

class SharedData(dict):
    """
    Data structure built on top of a dict object that allows asserting values under keys exist.
    """

    def get(self, key: str):
        """
        Overrides get and asserts the key exists within SharedData.
        """

        assert key in self, f"Key: {key} is not in shared_data"
        return self[key]

Thanks to this laziness, instead of throwing an error if a key isn’t present, I automatically learn about it via assert. It’s a simple change but provides a lot of information during testing and allows errors to be detected much faster.

Data is shared throughout the entire testing session, so the fixture looks like this:

@pytest.fixture(scope="session")
def shared_data():
    """
    Provides a SharedData instance to store data that can be shared across tests within the
    same session scope. Useful for sharing setup information like IDs or tokens
    without repeating database calls.

    Yields:
        SharedData: An empty dictionary base class to be populated with shared data as needed.
    """
    data = SharedData()
    yield data

Now all your tests can share data with each other throughout the entire session, and you’ll also get information about missing data.

Summary

The presented fixtures help organize your tests and focus on their true purpose—securing your application against business errors. Depending on your needs, decide which customer paths you want to test and ensure peace of mind and convenience. Testing doesn’t have to be boring and time-consuming.

Alex

P.S.: You can find my testing package in my repository at https://github.com/alex-b27g/blog