测试模式

编写能发现缺陷的测试，而不是仅仅通过的测试。 —— 通过覆盖率建立信心，通过隔离实现速度。

测试金字塔

规则： 如果你的端到端测试数量超过单元测试，请倒置金字塔结构。

单元测试模式

核心模式

安排-行动-断言（AAA）

所有单元测试的默认结构。清晰地分离设置、执行和验证部分，使测试更易读且易于维护。

// 清晰的 AAA 结构
test('计算含税订单总价', () => {
  // 安排
  const items = [{ price: 10, qty: 2 }, { price: 5, qty: 1 }];
  const taxRate = 0.08;

  // 行动
  const total = calculateTotal(items, taxRate);

  // 断言
  expect(total).toBe(27.0);
});

测试替身（Test Doubles）

根据场景选择合适的测试替身类型。每种都有其特定用途。

// 桩 —— 控制间接输入
const getUser = jest.fn().mockResolvedValue({ id: 1, name: 'Alice' });

// 间谍 —— 观察而不替换
const spy = jest.spyOn(logger, 'warn');
processInvalidInput(data);
expect(spy).toHaveBeenCalledWith('Invalid input received');

// 假实现 —— 轻量级替代
class FakeUserRepo implements UserRepository {
  private users = new Map<string, User>();
  async save(user: User) { this.users.set(user.id, user); }
  async findById(id: string) { return this.users.get(id) ?? null; }
}

参数化测试

当相同逻辑需要在多种输入下验证时使用参数化测试。可避免重复代码，同时提供全面覆盖。

// Vitest/Jest
test.each([
  ['hello', 'HELLO'],
  ['world', 'WORLD'],
  ['', ''],
  ['123abc', '123ABC'],
])('toUpperCase(%s) 返回 %s', (input, expected) => {
  expect(input.toUpperCase()).toBe(expected);
});

# pytest
@pytest.mark.parametrize("input,expected", [
    ("hello", "HELLO"),
    ("world", "WORLD"),
    ("", ""),
])
def test_to_upper(input, expected):
    assert input.upper() == expected

// Go —— 表驱动测试（惯用写法）
func TestAdd(t *testing.T) {
    tests := []struct {
        name     string
        a, b     int
        expected int
    }{
        {"positive", 2, 3, 5},
        {"zero", 0, 0, 0},
        {"negative", -1, -2, -3},
    }
    for _, tc := range tests {
        t.Run(tc.name, func(t *testing.T) {
            if got := Add(tc.a, tc.b); got != tc.expected {
                t.Errorf("Add(%d,%d) = %d, want %d", tc.a, tc.b, got, tc.expected)
            }
        })
    }
}

集成测试模式

数据库测试策略

// 事务回滚模式（Prisma）
beforeEach(async () => {
  await prisma.$executeRaw`BEGIN`;
});
afterEach(async () => {
  await prisma.$executeRaw`ROLLBACK`;
});

test('在数据库中创建用户', async () => {
  const user = await createUser({ name: 'Alice', email: 'a@b.com' });
  const found = await prisma.user.findUnique({ where: { id: user.id } });
  expect(found?.name).toBe('Alice');
});

API 测试

// Supertest（Node.js）
import request from 'supertest';
import { app } from '../src/app';

describe('POST /api/users', () => {
  it('创建用户并返回 201', async () => {
    const res = await request(app)
      .post('/api/users')
      .send({ name: 'Alice', email: 'alice@test.com' })
      .expect(201);

    expect(res.body).toMatchObject({
      id: expect.any(String),
      name: 'Alice',
    });
  });

  it('对无效邮箱返回 400', async () => {
    await request(app)
      .post('/api/users')
      .send({ name: 'Alice', email: 'not-an-email' })
      .expect(400);
  });
});

模拟的最佳实践

模拟边界，而非实现

基本原则：应在系统边界（外部 API、数据库、文件系统）处进行模拟，绝不应模拟内部领域逻辑。

// 错误示例 —— 模拟内部实现
jest.mock('./utils/formatDate');  // 重构时容易失效

// 正确示例 —— 模拟外部边界
jest.mock('./services/paymentGateway');  // 第三方 API 是边界

何时模拟，何时不模拟

依赖注入以提升可测试性

将代码结构设计为可在测试中替换依赖项。这是提升代码可测试性的最关键模式。

// 可注入的依赖 —— 易于测试
class OrderService {
  constructor(
    private paymentGateway: PaymentGateway,
    private inventory: InventoryService,
    private notifier: NotificationService,
  ) {}

  async placeOrder(order: Order): Promise<OrderResult> {
    const stock = await this.inventory.check(order.items);
    if (!stock.available) return { status: 'out_of_stock' };

    const payment = await this.paymentGateway.charge(order.total);
    if (!payment.success) return { status: 'payment_failed' };

    await this.notifier.send(order.userId, 'Order confirmed');
    return { status: 'confirmed', id: payment.transactionId };
  }
}

// 在测试中 —— 注入假实现
const service = new OrderService(
  new FakePaymentGateway(),
  new FakeInventory({ available: true }),
  new FakeNotifier(),
);

框架速查表

测试质量检查清单

命名规范： test_[单元]_[场景]_[预期结果] 或 should [执行某操作] when [条件 Y]

覆盖率策略

应达到何种覆盖率

不应测试的内容

测试组织结构

src/
├── services/
│   ├── order.service.ts
│   └── order.service.test.ts      # 与源码共存的单元测试
├── api/
│   └── routes/
│       └── orders.ts
tests/
├── integration/
│   ├── api/
│   │   └── orders.test.ts         # API 集成测试
│   └── db/
│       └── order.repo.test.ts     # 数据库集成测试
├── e2e/
│   ├── pages/                     # 页面对象
│   │   └── checkout.page.ts
│   └── specs/
│       └── checkout.spec.ts       # 端到端测试用例
└── helpers/
    ├── factories.ts               # 测试数据工厂
    └── setup.ts                   # 全局测试设置

规则： 单元测试与源码共存。集成测试和端到端测试应放在独立目录中。

反模式

markdown

测试模式

常见反模式

绝对不要做

1. 绝不要测试实现细节而非行为 — 测试应验证代码做什么，而非如何做
2. **绝不要在测试中使用 sleep()** — 使用显式等待、轮询、事件或自动重试的断言
3. 绝不要在测试间共享可变状态 — 每个测试应独立设置和清理自身状态
4. 绝不要编写无断言的测试 — 不断言的测试无法证明任何事情
5. 绝不要模拟内部领域逻辑 — 仅在系统边界（网络、数据库、文件系统、时钟）处模拟
6. 绝不要跳过测试而不关联问题并制定恢复计划 — 跳过的测试会逐渐变成永久漏洞
7. 绝不要让测试套件处于持续失败状态 — 修复或移除并说明理由后再继续
8. 绝不要以 100% 覆盖率为目标 — 覆盖率是工具，不是目标；关键路径上的强断言优于全局弱断言

总结

记住： 测试是一张安全网 — 一个快速、可靠的测试套件让你可以毫无畏惧地重构，并自信地交付。