Good and Bad Tests

好测试与坏测试

Good Tests

好测试

Integration-style: Test through real interfaces, not mocks of internal parts.

集成风格：通过真实接口测试，而非模拟内部组件。

// GOOD: Tests observable behavior
test("user can checkout with valid cart", async () => {
  const cart = createCart();
  cart.add(product);
  const result = await checkout(cart, paymentMethod);
  expect(result.status).toBe("confirmed");
});

// 好测试：测试可观察的行为
test("user can checkout with valid cart", async () => {
  const cart = createCart();
  cart.add(product);
  const result = await checkout(cart, paymentMethod);
  expect(result.status).toBe("confirmed");
});

Characteristics:

特征：

Tests behavior users/callers care about
Uses public API only
Survives internal refactors
Describes WHAT, not HOW
One logical assertion per test

测试用户/调用者关心的行为
仅使用公共 API
能经受内部重构
描述 WHAT（做什么），而非 HOW（怎么做）
每个测试一个逻辑断言

Bad Tests

坏测试

Implementation-detail tests: Coupled to internal structure.

实现细节测试：与内部结构耦合。

// BAD: Tests implementation details
test("checkout calls paymentService.process", async () => {
  const mockPayment = jest.mock(paymentService);
  await checkout(cart, payment);
  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
});

// 坏测试：测试实现细节
test("checkout calls paymentService.process", async () => {
  const mockPayment = jest.mock(paymentService);
  await checkout(cart, payment);
  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
});

Red flags:

危险信号：

Mocking internal collaborators
Testing private methods
Asserting on call counts/order
Test breaks when refactoring without behavior change
Test name describes HOW not WHAT
Verifying through external means instead of interface

模拟内部协作者
测试私有方法
对调用次数/顺序断言
重构时测试失败但行为未变
测试名称描述 HOW（怎么做）而非 WHAT（做什么）
通过外部手段而非接口验证

// BAD: Bypasses interface to verify
test("createUser saves to database", async () => {
  await createUser({ name: "Alice" });
  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
  expect(row).toBeDefined();
});

// GOOD: Verifies through interface
test("createUser makes user retrievable", async () => {
  const user = await createUser({ name: "Alice" });
  const retrieved = await getUser(user.id);
  expect(retrieved.name).toBe("Alice");
});

// 坏测试：绕过接口验证
test("createUser saves to database", async () => {
  await createUser({ name: "Alice" });
  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
  expect(row).toBeDefined();
});

// 好测试：通过接口验证
test("createUser makes user retrievable", async () => {
  const user = await createUser({ name: "Alice" });
  const retrieved = await getUser(user.id);
  expect(retrieved.name).toBe("Alice");
});

Tautological tests: Expected value restates the implementation, so the test passes by construction.

同义反复测试：期望值重述了实现，因此测试按构造通过。

// BAD: Expected value is recomputed the way the code computes it
test("calculateTotal sums line items", () => {
  const items = [{ price: 10 }, { price: 5 }];
  const expected = items.reduce((sum, i) => sum + i.price, 0);
  expect(calculateTotal(items)).toBe(expected);
});

// GOOD: Expected value is an independent, known literal
test("calculateTotal sums line items", () => {
  expect(calculateTotal([{ price: 10 }, { price: 5 }])).toBe(15);
});

// 坏测试：期望值以代码的相同方式重新计算
test("calculateTotal sums line items", () => {
  const items = [{ price: 10 }, { price: 5 }];
  const expected = items.reduce((sum, i) => sum + i.price, 0);
  expect(calculateTotal(items)).toBe(expected);
});

// 好测试：期望值是独立的已知字面量
test("calculateTotal sums line items", () => {
  expect(calculateTotal([{ price: 10 }, { price: 5 }])).toBe(15);
});