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.