Case Study: The Test That Saved a Launch

The Scenario

Priya Ramirez had been at CloudCart — an e-commerce startup — for six months when her team got the green light for the biggest product launch since the company's founding: a real-time promotional pricing engine. The idea was straightforward: when a customer added items to their cart, the system would dynamically calculate discounts based on bundle deals, loyalty points, and limited-time promotions.

The launch was scheduled for Black Friday. The feature had to be flawless. A pricing error during the biggest shopping day of the year could cost the company millions — either by overcharging customers (legal liability, PR disaster) or by undercharging them (financial catastrophe).

Priya was responsible for the discount calculation module.

The First Version: "It Works on My Machine"

Priya wrote the pricing logic quickly. It was elegant: a chain of discount rules applied in sequence. Buy 3, get 10% off. Loyalty tier Gold adds another 5%. Promo code BLACKFRI takes 20% off the highest-priced item. She tested it manually with a handful of scenarios. Everything looked right.

Her colleague, Marcus, reviewed the code and asked: "What happens if someone applies a percentage discount and a fixed-dollar discount to the same item?"

Priya thought for a moment. "They wouldn't do that."

Marcus raised an eyebrow. "On Black Friday? With a coupon code and a loyalty discount? They absolutely will."

Building the Test Suite

Marcus convinced Priya to write automated tests before the code went any further. They started with the obvious cases:

def test_single_item_no_discount():
    cart = [{"name": "Widget", "price": 29.99, "quantity": 1}]
    assert calculate_total(cart, discounts=[]) == 29.99

def test_buy_three_get_ten_percent():
    cart = [{"name": "Widget", "price": 10.00, "quantity": 3}]
    discounts = [{"type": "bundle", "min_quantity": 3, "percent": 10}]
    total = calculate_total(cart, discounts=discounts)
    assert total == pytest.approx(27.00)  # 30 - 10% = 27

These passed. Then they wrote the test Marcus was worried about:

def test_stacked_discounts():
    """Percentage discount + loyalty discount on same item."""
    cart = [{"name": "Premium Widget", "price": 100.00, "quantity": 1}]
    discounts = [
        {"type": "promo", "percent": 20},
        {"type": "loyalty", "percent": 5},
    ]
    total = calculate_total(cart, discounts=discounts)
    # Expected: 20% off = $80, then 5% off $80 = $76.00
    assert total == pytest.approx(76.00)

The test failed. The function returned $75.00 instead of $76.00.

The Bug

The discount calculation was applying both percentages to the original price rather than sequentially:

# Buggy version: discounts applied to original price
# 20% of 100 = 20, 5% of 100 = 5, total discount = 25, final = 75

# Correct version: discounts applied sequentially
# 20% of 100 = 20, price becomes 80
# 5% of 80 = 4, price becomes 76

One dollar difference. Seems small. But across 200,000 transactions on Black Friday, that's $200,000 in incorrectly calculated prices. And in some edge cases — where multiple large percentage discounts stacked — the error was much larger. One test case with four stacked discounts showed a $12 difference on a single order.

The Edge Cases Nobody Thought Of

Emboldened by catching one bug, Priya and Marcus went hunting for edge cases:

def test_discount_greater_than_price():
    """What if stacked discounts exceed 100%?"""
    cart = [{"name": "Widget", "price": 50.00, "quantity": 1}]
    discounts = [
        {"type": "promo", "percent": 60},
        {"type": "loyalty", "percent": 50},
    ]
    total = calculate_total(cart, discounts=discounts)
    assert total >= 0  # Price should never go negative

Failed. The function returned -$5.00. A customer could theoretically get paid to buy a product.

def test_zero_quantity():
    """Cart item with quantity zero."""
    cart = [{"name": "Widget", "price": 29.99, "quantity": 0}]
    assert calculate_total(cart, discounts=[]) == 0.00

def test_empty_cart():
    """No items in cart."""
    assert calculate_total([], discounts=[]) == 0.00

def test_very_large_order():
    """Stress test: 1000 items with multiple discounts."""
    cart = [{"name": f"Item {i}", "price": 9.99, "quantity": 10}
            for i in range(100)]
    discounts = [{"type": "promo", "percent": 15}]
    total = calculate_total(cart, discounts=discounts)
    expected = sum(9.99 * 10 for _ in range(100)) * 0.85
    assert total == pytest.approx(expected, rel=1e-2)

Each edge case revealed a new bug or a missing guard clause. By the time they finished, the test suite had 47 tests. All passing.

The Save

Two days before Black Friday, another developer — working on the inventory module — changed the data format of cart items. Instead of "price": 29.99 (a float), items now arrived as "price": "29.99" (a string from the database). This was a minor change, and the developer's own tests passed.

But Priya's tests caught it immediately:

FAILED test_pricing.py::test_single_item_no_discount
    assert calculate_total(cart, discounts=[]) == 29.99
    TypeError: unsupported operand type(s) for *: 'str' and 'int'

The pricing module couldn't multiply a string by a quantity. Without the test suite, this bug would have gone live on Black Friday. Every single order would have crashed at checkout.

The fix took three minutes. Finding it without tests might have taken hours — at 3 AM on Black Friday, with thousands of customers unable to complete purchases.

The Aftermath

CloudCart's Black Friday went smoothly. The pricing engine processed 247,000 orders without a single calculation error. After the holiday, the engineering director asked Priya to present her testing approach to the whole team.

Her slide deck had one key message: "The tests didn't slow us down. The bugs we caught would have."

The team adopted a policy: no pricing code ships without tests. Not because management mandated it, but because the developers themselves saw what the alternative looked like.

Discussion Questions

  1. The stacked discount bug produced a $1 difference per order. Priya might have dismissed this as rounding. Why is it important to investigate even small discrepancies in test output?

  2. Marcus's question — "What happens if someone applies two discount types to the same item?" — is a classic combination test. Why are combinations of features often where bugs hide? How does this relate to the concept of integration testing from Section 13.2?

  3. The inventory developer's format change broke the pricing module even though it had nothing to do with pricing. This is a regression — something that used to work stopped working because of an unrelated change. How does a test suite protect against regressions? What would have happened without one?

  4. Priya initially said "They wouldn't do that" about stacked discounts. How does this kind of assumption lead to bugs? What mindset should you adopt when thinking about edge cases?

  5. Connection to Chapter 11: How could the pricing function have used error handling (try/except) to gracefully handle the string-to-float data format change instead of crashing?

Mini-Project

Choose a real-world pricing or calculation scenario (restaurant bill splitting, tax calculation, GPA computation, currency conversion). Write:

  1. The function that performs the calculation
  2. At least 10 tests covering normal cases, edge cases, and error cases
  3. At least one test that reveals a bug you didn't anticipate when writing the function

Reflect: which test was the most valuable? Which bug would have been hardest to find without automated testing?