Testing Financial Software: Building Confidence in Your Code

Why Financial Software Needs More Testing, Not Less

Every piece of software benefits from testing, but financial software operates in a category where bugs have direct monetary consequences. A rounding error in a pricing model does not just produce wrong output — it misprices trades, miscalculates risk, or reports incorrect P&L. These are not abstract problems; they are the kind of issues that lead to trading losses, regulatory fines, and front-page news stories.

Testing is not about achieving 100% code coverage for the sake of a metric. It is about building justified confidence that your code does what it should, handles edge cases correctly, and fails gracefully when things go wrong.

---

The Testing Pyramid

The testing pyramid is a practical framework for how to distribute your testing effort:

Unit tests (the base — most numerous): test individual functions in isolation. Fast, cheap, and the first line of defence.

Integration tests (the middle): test that components work together correctly. Database queries return expected results, API endpoints handle requests properly, services communicate as expected.

End-to-end tests (the top — fewest): test complete workflows from start to finish. Slow and fragile, but catch issues that lower-level tests miss.

The pyramid shape matters: if you have hundreds of end-to-end tests but few unit tests, your test suite is slow, brittle, and hard to debug when something fails.

---

Unit Testing with pytest

pytest is the standard testing framework in Python. Its simplicity is its greatest strength — tests are just functions that make assertions:

# test_pricing.py
import pytest
from pricing import calculate_vwap, calculate_simple_return

def test_vwap_basic():
    prices = [100.0, 101.0, 99.0]
    volumes = [1000, 2000, 1500]
    result = calculate_vwap(prices, volumes)
    expected = (100*1000 + 101*2000 + 99*1500) / (1000 + 2000 + 1500)
    assert abs(result - expected) < 1e-10

def test_vwap_zero_volume():
    """Edge case: what happens with zero total volume?"""
    prices = [100.0, 101.0]
    volumes = [0, 0]
    result = calculate_vwap(prices, volumes)
    assert result == 0.0  # Should handle gracefully, not divide by zero

def test_simple_return():
    assert calculate_simple_return(100.0, 110.0) == pytest.approx(0.10)
    assert calculate_simple_return(100.0, 90.0) == pytest.approx(-0.10)
    assert calculate_simple_return(100.0, 100.0) == pytest.approx(0.0)

def test_simple_return_zero_price():
    with pytest.raises(ValueError, match="Entry price cannot be zero"):
        calculate_simple_return(0.0, 100.0)

Fixtures: Reusable Test Setup

When multiple tests need the same data, fixtures eliminate duplication:

@pytest.fixture
def sample_portfolio():
    return {
        "AAPL": {"qty": 100, "avg_price": 150.25},
        "GOOGL": {"qty": 50, "avg_price": 2800.50},
        "MSFT": {"qty": 75, "avg_price": 380.00},
    }

@pytest.fixture
def sample_trades():
    return [
        {"symbol": "AAPL", "qty": 100, "price": 150.25, "side": "BUY"},
        {"symbol": "AAPL", "qty": 50, "price": 155.00, "side": "SELL"},
    ]

def test_portfolio_value(sample_portfolio):
    total = sum(p["qty"] * p["avg_price"] for p in sample_portfolio.values())
    assert total == pytest.approx(184_562.5)

def test_net_position(sample_trades):
    net = sum(t["qty"] if t["side"] == "BUY" else -t["qty"] for t in sample_trades)
    assert net == 50

Parametrised Tests

Test the same logic with multiple inputs concisely:

@pytest.mark.parametrize("entry,exit_price,expected", [
    (100.0, 110.0, 0.10),
    (100.0, 90.0, -0.10),
    (50.0, 75.0, 0.50),
    (200.0, 200.0, 0.0),
])
def test_return_calculation(entry, exit_price, expected):
    assert calculate_simple_return(entry, exit_price) == pytest.approx(expected)

---

Testing Financial Edge Cases

Financial software has specific edge cases that general software does not:

def test_floating_point_precision():
    """Financial calculations must handle floating point correctly."""
    # 0.1 + 0.2 != 0.3 in floating point
    result = calculate_total([0.1, 0.2])
    assert result == pytest.approx(0.3, abs=1e-10)

def test_negative_prices_rejected():
    """Prices should never be negative."""
    with pytest.raises(ValueError):
        create_trade(symbol="AAPL", price=-10.0, quantity=100)

def test_weekend_dates_skipped():
    """Business day calculations should skip weekends."""
    friday = date(2024, 1, 5)
    next_business = next_business_day(friday)
    assert next_business == date(2024, 1, 8)  # Monday

def test_currency_conversion():
    """Multi-currency positions must convert correctly."""
    gbp_position = Position("VOD.L", 1000, 98.50, currency="GBP")
    usd_value = gbp_position.value_in("USD", rate=1.27)
    assert usd_value == pytest.approx(125_095.0)

---

Integration Testing

Unit tests verify individual pieces. Integration tests verify they work together:

@pytest.fixture
def test_database():
    """Create a temporary test database."""
    db = create_test_database()
    db.execute("INSERT INTO products VALUES ('AAPL', 'Apple Inc', 'Technology')")
    yield db
    db.cleanup()

def test_trade_insertion_updates_position(test_database):
    """Inserting a trade should automatically update the position table."""
    insert_trade(test_database, symbol="AAPL", qty=100, price=150.0, side="BUY")

    position = get_position(test_database, "AAPL")
    assert position.quantity == 100
    assert position.avg_price == 150.0

def test_trade_insertion_records_audit(test_database):
    """Every trade should create an audit log entry."""
    insert_trade(test_database, symbol="AAPL", qty=100, price=150.0, side="BUY")

    audit_entries = get_audit_log(test_database, "AAPL")
    assert len(audit_entries) == 1
    assert audit_entries[0].action == "TRADE_INSERT"

---

What to Test and What Not To

Always test: business logic (pricing, risk, P&L), edge cases (zero values, negative numbers, empty inputs), error handling (what happens when things fail), boundary conditions (end of month, year-end, market close).

Usually test: data transformations, API request/response contracts, database queries.

Rarely test: third-party library internals, simple getters/setters, UI layout details.

Testing connects directly to debugging — tests that fail tell you exactly where to look. It is also the foundation for CI/CD pipelines: automated tests that run on every push are the safety net that makes continuous deployment possible.

Good tests are an investment. They take time to write, but they save orders of magnitude more time in prevented bugs, faster debugging, and the confidence to refactor code without fear.