When a Tiny Bug in C# Breaks Everything: London vs. Classical Testing

Ever had a tiny bug in your C# code crash your entire test suite? 😩 Let’s break down why that happens—and how your testing style (London vs. Classical) changes your debugging experience.

Inspired by “Unit Testing: Principles, Practices, and Patterns” by Vladimir Khorikov, here’s a relatable C# example to highlight the difference!

🛒 The Scenario: A Simple Shopping Cart System

Imagine an e-commerce setup with:

Cart– Manages items, calculates totals
OrderProcessor– Handles orders (depends on Cart)
PaymentService– Processes payments (depends on OrderProcessor)

Now suppose you accidentally break the Cartclass. How does each testing style react?

1️⃣ London-Style Tests (Isolated with Mocks)

In London-style testing, dependencies are mocked, so only tests for the broken component (Cart) fail.

// London-style test for OrderProcessor (using Moq)
[Fact]
public void OrderProcessor_CreatesInvoice_ReturnsCorrectTotal()
{
    var mockCart = new Mock<ICart>();
    mockCart.Setup(c => c.GetTotal()).Returns(100); // Mocked Cart
    var processor = new OrderProcessor(mockCart.Object);

    var result = processor.CreateInvoice();    
    Assert.Equal(100, result); // ✅ Passes—even if the REAL Cart is broken!
}

✅ Pros: Fast, focused tests. Easy to pinpoint failures (e.g., Cart only).
❌ Cons: Can give false confidence—misses integration bugs.

In classical testing, real dependencies are used. So if Cartis broken, tests for OrderProcessorand even PaymentServicestart failing too.

// Classical test for OrderProcessor
[Fact]
public void OrderProcessor_CreatesInvoice_ReturnsCorrectTotal()
{
    var cart = new Cart(); // Real Cart instance
    cart.AddItem("Book", 50);
    var processor = new OrderProcessor(cart);

    var result = processor.CreateInvoice();    
    Assert.Equal(50, result); // ❌ FAILS if Cart.GetTotal() is broken!
}

✅ Pros: Detects integration issues early.
❌ Cons: One bug can trigger a failure avalanche 🌊

🧠 Why This Matters

London-style tests are precise and fast—but can miss real-world breakages.
Classical tests offer stronger guarantees—but debugging them can feel like “whack-a-mole.” 🔨

📘 Khorikov’s Insight

Classical tests align better with the Test Pyramid, emphasizing integration and reducing over-reliance on mocks.
A failure avalanche often points to mission-critical code. If breaking Cartcauses 50 failures? That’s a signal—it’s important!

✅ Silver Linings