Test Fixtures and Mocking

A function that calculates a position's risk needs a portfolio, some prices, and a volatility estimate to run at all. Write a test for it and you immediately face a choice: build that input data fresh, by hand, inside every single test, or set it up once and reuse it. And if the function also calls out to a live market data feed or an order-routing API to do its job, a further problem appears, a unit test that hits a real broker every time it runs is slow, might fail because of a network hiccup that has nothing to do with the code being tested, and could, in the worst case, place a real order.

A fixture is a piece of reusable test setup, a sample portfolio, a small synthetic price series, a mock configuration object, defined once and then handed to any test that needs it, instead of being rebuilt from scratch inline in every test function. Most testing frameworks (pytest fixtures, for example) let a fixture also handle teardown: closing a database connection or deleting a temp file after the test finishes, whether or not the test passed.

Mocking replaces a real external dependency, a live data feed, a broker's order API, the system clock, a slow database, with a fake stand-in object that behaves predictably: it returns a scripted value instead of doing the real thing. A mocked broker client's send_order() might just record that it was called with certain arguments and return a canned "filled" response, without any network call actually happening.

Worked example. A function size_position(portfolio, price_feed, risk_limit) needs to be tested. Without fixtures or mocks, every test would construct a portfolio object, connect to a real price feed, and set a risk limit, all inline, repeated, verbose, and slow because price_feed hits a live API. Instead: a fixture sample_portfolio returns a fixed, hand-built portfolio object; a fixture mock_price_feed returns a fake feed object whose .get_price("AAPL") is hardcoded to return $150.00 with no network call; the risk limit is just passed as a plain argument. Ten different test cases, normal sizing, a zero-risk-limit edge case, a portfolio already at its limit, all reuse the same two fixtures, each test runs in milliseconds, and none of them depend on markets being open or a real API key being configured.

What this means in practice

Fixtures keep tests short and consistent by centralizing setup in one place instead of copy-pasting it everywhere; mocking keeps tests fast and deterministic by removing dependence on real external systems that are slow, flaky, or dangerous to actually call from a test suite. Neither replaces the need to test the real integration eventually, mocking a broker's API assumes the mock behaves like the real API, an assumption that only integration and end-to-end testing actually checks.