Tested But Unwired

The function had full test coverage. Every test passed. The import was clean. The lint check had nothing to flag.

The /health endpoint always returned ok.

The cache had been stale for 6 hours.

This is "Tested But Unwired" — a specific class of production bug that lives in the gap between what your test suite measures and what your system actually does. Unit tests measure whether a function works when called. They do not measure whether the function is called at all.

Defining the Bug Class

has three simultaneous conditions that must all be true:

1. The function has unit tests that pass
2. The function is imported by production code
3. The function is never called from any actual production path

All three conditions together create the danger. One or two alone would be caught by standard tooling. All three together create a credible lie — the kind of bug that survives code review, CI, and casual inspection because every individual signal says the code is fine.

The InDecision Example

The InDecision engine has a health utility module with staleness detection. is_db_degraded() checks whether the last cache write timestamp exceeds a threshold — if the cache has not been written to recently, the function returns True and the health check should surface a degraded state.

The function had complete unit tests. Edge cases covered. Threshold logic verified. All green.

It was imported in deps.py as a dependency function — the standard pattern for injecting health checks into FastAPI routes.

The /health route never called it.

# What deps.py contained
from health_utils import is_db_degraded

async def get_db_health():
    degraded = is_db_degraded()  # this function was defined but never injected
    return {"degraded": degraded}

# What the /health route actually contained
@router.get("/health")
async def health_check():
    return {"status": "ok"}  # hardcoded — no dependency injection

The route was rewritten at some point during a refactor. The dependency injection was dropped. The get_db_health function in deps.py still existed, still imported is_db_degraded, still had the correct logic — but it was never wired into the route. The route returned a hardcoded ok.

For 6 hours of cache staleness, every monitoring ping returned healthy. Every alert was silent. The system appeared operational. It was operating on stale data.

Why This Happens

Refactors create orphans. A route gets rewritten, a function gets replaced, a new pattern gets introduced — and the old code is not fully cleaned up. The tests stay green because the tests were written against the function, not against the production path. The import stays clean because the import is used — just never from a code path that matters.

The test suite is not lying. It is telling you the truth about a function in isolation. The production system is the one lying, because the path from HTTP request to health utility never executes.

This is why coverage percentages are misleading. is_db_degraded() had 100% coverage in the test suite. 0% execution in production operation.

The Detection Method: Call Chain Tracing

The only reliable way to find Tested But Unwired code is to trace the call chain starting from production entry points. Not from test files. Not from imports. From where execution actually begins.

For a health endpoint, the entry point is the HTTP handler. You start there and trace outward.

# Find all functions in the health utilities module
grep -n "^def \|^async def " health_utils.py

# Trace which routes and handlers actually call each one
grep -rn "is_db_degraded\|check_cache_health\|verify_connection" routers/ main.py

# If nothing in routers/ or main.py calls the function — it is unwired
# The presence of the call in deps.py does NOT count unless deps.py is injected

The critical step most people skip: verifying that the intermediate caller (in this case deps.py) is itself injected into the route. An import chain of health_utils → deps.py → nowhere is an orphan. The import in deps.py is real. The wire to the route is missing.

# Verify the dependency is actually injected into the route
grep -n "get_db_health\|Depends(get_db_health)" routers/health.py

# If this returns nothing — the dependency exists but is not wired in

The Second Example: locals() Assignment

The same audit cycle surfaced a second instance of this pattern in a different form. A configuration loader used locals()[key] = val inside a loop to dynamically assign values to local variables.

def load_config(config_dict: dict) -> dict:
    result = {}
    for key, val in config_dict.items():
        locals()[key] = val  # this does nothing
        result[key] = val    # this is the actual work
    return result

The locals()[key] = val assignment is syntactically valid Python. It executes without error. It has no effect. Python's locals() returns a snapshot dictionary — writing to it does not modify the actual local namespace. The loop ran, the assignment succeeded, the function returned correctly — because result[key] = val was doing the real work on the line below.

Six tests covered this function. All passed. None of them checked whether locals() had been mutated — because that was not what the tests were measuring. The dead assignment was invisible to the entire test suite.

This is the same class of bug in a different form: code that executes, produces no error, passes tests, and does nothing useful.

The Audit Rule

During any code audit, every health, monitoring, and degradation-detection function gets a full call chain trace. The chain has four links:

Definition → Import → Call Site → HTTP Handler (or Cron Trigger or Event Listener)

A break at any link is a P0. Not a P2 technical debt item. A P0 — because a monitoring function that is not called is not monitoring anything. It is documentation that looks like code.

Apply this trace to the entry points that matter most: health endpoints, degradation detectors, staleness checks, anomaly detection. These are the functions your alerting and observability depend on. A dead test for a utility function is a code quality issue. A dead health check is a blind spot in your production monitoring.

What to Add to Your Audit Checklist

Any code audit covering a service with monitoring or health-check logic should include this step explicitly:

1. List every function with "health", "degraded", "stale", "check", or "anomaly" in its name
2. For each: trace the call chain from definition to production entry point
3. If the chain is broken: classify as P0 and fix before any other issues

You will find at least one. Systems that have been refactored — which is every system — accumulate orphaned monitoring code. The tests stay green. The coverage looks fine. The system is flying blind.

Tracing the call chain is the only way to know the difference.