Testing and Test-Driven Development

Why Tests Enable Clean Code

I once inherited a payment module with no tests. The business wanted to add support for a new tax region. I traced the logic through six files, made what I thought was a surgical change, and deployed. A week later, finance noticed that discounts were being applied twice in edge cases.

The bug had nothing to do with my change. It was pre-existing. But without tests, I had no way to know. I was afraid to touch the code—and fear of change is how code rots.

Tests change that equation. They give you permission to improve.

Tests as a Safety Net for Refactoring

Refactoring means changing structure without changing behavior. The only way to know you didn't break anything is to run the code. Tests automate that check.

Without tests:

Javascript

// You want to extract this logic, but you're not sure what else depends on it
function calculateOrderTotal(order) {
  let total = 0;
  for (const item of order.items) {
    total += item.price * item.quantity;
  }
  if (order.customer.isPremium) {
    total *= 0.9;  // 10% discount
  }
  total += total * TAX_RATE;
  return Math.round(total * 100) / 100;
}

You see duplicated rounding logic elsewhere. You want to extract a roundCurrency() helper. But you hesitate. What if something relies on the exact floating-point behavior? What if premium discount interacts with tax in a way you'll miss?

With tests:

Javascript

describe('calculateOrderTotal', () => {
  it('applies 10% discount for premium customers', () => {
    const order = {
      items: [{ price: 100, quantity: 1 }],
      customer: { isPremium: true }
    };
    expect(calculateOrderTotal(order)).toBe(99.00);
  });

  it('includes tax in the final total', () => {
    const order = {
      items: [{ price: 100, quantity: 1 }],
      customer: { isPremium: false }
    };
    expect(calculateOrderTotal(order)).toBe(108.50);
  });
});

Now you refactor with confidence. Run the tests. If they pass, you didn't break the contract. If they fail, you know exactly what broke.

Real refactoring confidence: I've seen teams extract a 500-line function into a dozen smaller ones in a single PR. They could do it because 200 tests ran on every change. No tests? That refactor would have been a multi-week, high-anxiety project.

Tests as Documentation

A test is executable specification. It shows how the code is supposed to be used and what it guarantees.

Compare these:

Comment (lies, goes stale):

Javascript

/**
 * Calculates the order total. Applies discounts for premium users.
 * Handles tax. Returns rounded value.
 */
function calculateOrderTotal(order) { ... }

Test (executable, verified):

Javascript

it('applies 10% discount for premium customers before adding tax', () => {
  const order = {
    items: [{ price: 100, quantity: 1 }],
    customer: { isPremium: true }
  };
  expect(calculateOrderTotal(order)).toBe(99.00);
});

The test tells you: premium discount is 10%, it's applied before tax, and the result is rounded to two decimals. If someone "fixes" the code and breaks that behavior, the test fails. Comments don't fail. They just become wrong.

When onboarding, I tell new developers: read the tests first. They're the most accurate documentation in the codebase.

Tests Drive Better Design

Code that's hard to test is usually badly designed.

Consider:

Javascript

// Hard to test: direct database call, no seam
async function getUserOrders(userId) {
  const db = await connectToDatabase();  // Can't inject a fake
  const orders = await db.query('SELECT * FROM orders WHERE user_id = ?', [userId]);
  return orders.map(formatOrder);
}

To test this, you'd need a real database or a complex mock of the connection. The design has no seam.

Better:

Javascript

// Testable: dependency injected
async function getUserOrders(userId, orderRepository) {
  const orders = await orderRepository.findByUserId(userId);
  return orders.map(formatOrder);
}

// In production: orderRepository = new DatabaseOrderRepository()
// In tests: orderRepository = { findByUserId: () => mockOrders }

Now you can test getUserOrders with a fake repository. No database. No network. Fast. Isolated.

Testability forces you to: inject dependencies, keep functions focused, avoid hidden global state. Those are the same forces that produce clean architecture. Tests don't just verify design—they push you toward it.

The Cost of Not Testing vs. the Cost of Testing

Cost of not testing:

Regression bugs. Every change risks breaking something. Without tests, you find out in production or during manual QA.
Fear of refactoring. Code accumulates cruft. No one dares touch it. Technical debt compounds.
Slower debugging. When something breaks, you have no baseline. You're debugging in the dark.
Documentation drift. Comments and docs go stale. Tests stay current or they fail.

Cost of testing:

Time to write. Tests take time. Especially at first, when you're learning.
Maintenance. Tests can break when requirements change. Brittle tests add friction.
False confidence. Bad tests pass when they shouldn't. They give a false sense of safety.

The trade-off tilts toward testing as the system grows. A 500-line script? Maybe you can get away with manual checks. A 50,000-line application with multiple developers? Tests are non-negotiable.

The key is good tests. Tests that verify behavior, not implementation. Tests that run fast. Tests that don't break when you refactor the internals. We'll cover that in later lessons.

Real Examples of Refactoring Confidence

Example 1: Renaming for clarity. A function was called proc. No one knew what it did. With 12 tests covering its behavior, we renamed it to applyScheduledDiscounts and refactored the internals. Tests passed. We knew we hadn't changed the contract.

Example 2: Performance optimization. A hot path was doing O(n²) lookups. We rewrote it to use a Map. Same inputs, same outputs. The tests verified that. The optimization shipped without a separate QA cycle.

Example 3: Library upgrade. We moved from an old HTTP client to a new one. 80 tests for our API layer caught every place where the new library's API differed. Without those tests, we would have found the bugs in production.

Tests don't prevent all bugs. They catch most regressions. They turn "I hope I didn't break anything" into "the tests pass—the contract holds."

Key insight: Tests enable clean code by giving you a safety net for refactoring, executable documentation that stays accurate, and design pressure toward testability (which correlates with good design). The cost of testing is real, but for any non-trivial codebase, the cost of not testing is higher. Write tests so you can improve the code without fear.