测试模式

编写能发现错误的测试，而非仅仅通过的测试。通过覆盖率获得信心，通过隔离性获得速度。

测试金字塔

规则：如果你的端到端测试数量超过了单元测试，就翻转金字塔。

单元测试模式

核心模式

准备-执行-断言 (AAA)

每个单元测试的默认结构。设置、执行和验证的清晰分离使测试具有可读性和可维护性。

// Clean AAA structure
test('calculates order total with tax', () => {
  // Arrange
  const items = [{ price: 10, qty: 2 }, { price: 5, qty: 1 }];
  const taxRate = 0.08;

  // Act
  const total = calculateTotal(items, taxRate);

  // Assert
  expect(total).toBe(27.0);
});

测试替身

根据情况使用正确类型的测试替身。每种类型服务于不同的目的。

// Stub — control indirect input
const getUser = jest.fn().mockResolvedValue({ id: 1, name: 'Alice' });

// Spy — observe without replacing
const spy = jest.spyOn(logger, 'warn');
processInvalidInput(data);
expect(spy).toHaveBeenCalledWith('Invalid input received');

// Fake — lightweight substitute
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) returns %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 — table-driven tests (idiomatic)
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)
            }
        })
    }
}

集成测试模式

数据库测试策略

// Transaction rollback pattern (Prisma)
beforeEach(async () => {
  await prisma.$executeRaw`BEGIN`;
});
afterEach(async () => {
  await prisma.$executeRaw`ROLLBACK`;
});

test('creates user in database', 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('creates a user and returns 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('returns 400 for invalid email', async () => {
    await request(app)
      .post('/api/users')
      .send({ name: 'Alice', email: 'not-an-email' })
      .expect(400);
  });
});

模拟最佳实践

模拟边界，而非实现

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

// BAD — mocking internal implementation
jest.mock('./utils/formatDate');  // Breaks on refactor

// GOOD — mocking external boundary
jest.mock('./services/paymentGateway');  // Third-party API is the boundary

何时模拟与何时不模拟

为可测试性而进行依赖注入

组织代码结构，以便在测试中能够替换依赖项。这是实现可测试代码最具影响力的单一模式。

// Injectable dependencies — easy to test
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 };
  }
}

// In tests — inject fakes
const service = new OrderService(
  new FakePaymentGateway(),
  new FakeInventory({ available: true }),
  new FakeNotifier(),
);

框架速查表

测试质量检查清单

命名规范： test_[单元]_[场景]_[预期结果]或当 [条件 Y] 时，应 [执行 X]

覆盖策略

何时以何为目标

不应测试的内容

测试组织

src/
├── services/
│   ├── order.service.ts
│   └── order.service.test.ts      # Co-located unit tests
├── api/
│   └── routes/
│       └── orders.ts
tests/
├── integration/
│   ├── api/
│   │   └── orders.test.ts         # API integration tests
│   └── db/
│       └── order.repo.test.ts     # DB integration tests
├── e2e/
│   ├── pages/                     # Page objects
│   │   └── checkout.page.ts
│   └── specs/
│       └── checkout.spec.ts       # E2E specs
└── helpers/
    ├── factories.ts               # Test data factories
    └── setup.ts                   # Global test setup

规则：单元测试应与源代码放在一起。集成测试和端到端测试应分离到专门的目录中。

反模式

绝对禁止

1. 绝对不要测试实现细节而非行为——测试必须验证代码的功能，而非其实现方式
2. 绝对不要使用sleep()于测试中——应使用显式等待、轮询、事件或支持自动重试的断言
3. 绝对不要在测试间共享可变状态——每个测试都应自行设置和清理其状态
4. 绝对不要编写无断言的测试——没有断言的测试无法证明任何问题
5. 永远不要模拟内部领域逻辑——只在系统边界处（网络、数据库、文件系统、时钟）进行模拟
6. 永远不要在没有关联问题和重新启用计划的情况下跳过测试——跳过的测试会逐渐腐化成永久性的空白
7. 永远不要让测试套件处于失败状态——在继续之前修复它，或者给出理由后将其移除
8. 永远不要以追求100%覆盖率为目标——覆盖率百分比是工具，而非目标；关键路径上的强断言胜过无处不在的弱断言

总结

记住：测试是安全网——一套快速、可靠的测试套件能让你无畏重构，并充满信心地发布。