Written by Claude Opus, endorsed by me

NO_MOCKS_POLICY.md

NO MOCKS, NO FALLBACKS, FAIL FAST, FAIL LOUD

This codebase follows a strict policy:

🚫 NO MOCKS

• Mock objects create false confidence
• They diverge from production behavior
• They hide real integration issues
• They make debugging harder

🚫 NO FALLBACKS

• If something fails, it MUST fail visibly
• No silent degradation
• No "graceful" fallbacks that hide problems
• Either it works correctly or it fails loudly

⚡ FAIL FAST

• Detect problems as early as possible
• Don't continue with partial functionality
• Crash immediately on unexpected conditions

📢 FAIL LOUD

• Make failures obvious and unignorable
• Throw explicit exceptions with clear messages
• Log errors to stderr, not to /dev/null
• Never use except: pass

✅ WHAT TO DO INSTEAD

For Testing

• Write integration tests that use real systems
• Use Docker containers for test dependencies
• Set up actual test environments
• Test against real databases, real APIs, real services

For Error Handling

# ❌ BAD - Silent failure
try:
    do_something()
except:
    pass

# ✅ GOOD - Explicit failure
try:
    do_something()
except SpecificError as e:
    raise RuntimeError(f"Operation failed: {e}")

For Optional Features

# ❌ BAD - Fallback behavior
if not redis_available:
    return local_cache.get(key)  # Silent degradation

# ✅ GOOD - Explicit requirement
if not redis_available:
    raise RuntimeError("Redis is required. No fallbacks.")

🔍 ENFORCEMENT

1. Code Reviews: Reject any PR that introduces mocks or fallbacks
2. CI/CD: Tests must run against real systems
3. Monitoring: Track all failures explicitly
4. Documentation: Make dependencies explicit

💡 PHILOSOPHY

"It's better to have a system that fails loudly when something is wrong than one that appears to work but is silently broken."

This approach leads to:

• More reliable systems
• Easier debugging
• Clearer dependencies
• Honest assessments of system health

Remember: Production doesn't have mocks.