# The Mock That Haunted the Entire Test Suite

_One line in one test file. 3,000 tests living in its shadow._

June 13, 2026 · 3 min · Amit Jethva

There's a category of bug that doesn't live in the failing test. It lives in some _other_ test, one you're not even looking at, which reached out from beyond and quietly rearranged the furniture for everyone else. Ours was a single line in `test_monitor_engine.py`:

```python
sys.modules['boto3'] = MagicMock()
```

Innocent-looking. Reasonable, even. "I don't want the real `boto3` in this test, so I'll swap in a mock." Sensible instinct. Catastrophic blast radius.

## Why it haunts

`sys.modules` is the global registry of imported modules for the _entire Python process_. When you assign `sys.modules['boto3'] = MagicMock()` at **module level**, that line runs the moment pytest _collects_ the file — not when the test runs, not in a fixture that tears down afterward. Just... permanently, for the rest of the session.

So now every other test that does `import boto3` doesn't get `boto3`. It gets a `MagicMock` that says "yes" to everything, returns more mocks when you call it, and never, ever raises. Your AWS scanner test "passes." Your claim-filing test "passes." They pass because they're talking to a hallucination that agrees with everything.

It's a poltergeist. The file that summoned it has long since finished running, but the haunting lingers in `sys.modules` for every test that comes after.

## The debugging experience

The maddening signature: **a test passes alone and fails in the suite — or worse, passes in the suite and fails alone.** Order-dependent failures are the ghost stories of testing. You run the one test, it's fine. You run all of them, chaos. The test itself is innocent; it's just standing where a previous test left a banana peel.

## What we actually did

We didn't exorcise the global mock (it had... reasons, and untangling it was its own quest). Instead we stopped fighting the ghost and **patched precisely where each test actually imports**, so each test brings its own controlled fake instead of relying on the global one:

```python
# claim_filing tests — patch where it's used, not the global module
patch("sla_monitoring.claim_filing.boto3")

# onboarding tests — same idea, local to the consumer
patch("app.services.onboarding_service.boto3")
```

The principle: **patch the name in the namespace that uses it, scoped to the test, torn down afterward.** A `with patch(...)` or `@patch` decorator cleans up after itself. `sys.modules['boto3'] = MagicMock()` cleans up after _nobody_.

## The moral

- **Module-level side effects in test files are global, permanent, and invisible.** They run at collection and outlive every test in the file.
- `sys.modules` assignment is a process-wide change with no undo. If you must mock an import, scope it with `patch` so teardown reverses it.
- When a test's pass/fail depends on _what ran before it_, you don't have a flaky test — you have a haunted one. Look for state leaking across the boundary: `sys.modules`, module globals, class attributes, singletons.

The call is coming from inside the suite.

---

_Amit Jethva is the CTO and co-founder of Nuvika Technologies Pvt Ltd, makers of [Fintropy](https://www.nuvikatech.com/Fintropy_Overview.html), a multi-cloud FinOps platform. Learn more at [nuvikatech.com](https://www.nuvikatech.com)._