测试与调试

用户: 运行所有测试

Claude: 我来运行项目中的所有测试。

Bash: npm test

测试输出：
> vitest run

 Test Files  12 passed (12)
      Tests  47 passed (47)
   Start at  10:23:45

所有 47 个测试全部通过。

用户: 只运行 src/services/payment.ts 相关的测试，并显示覆盖率

Claude: 我来运行相关测试并生成覆盖率报告。

Bash: npx vitest run src/services/payment.test.ts --coverage

expect(received).toBe(expected)

Expected: 42
Received: 38

TypeError: Cannot read property 'name' of undefined
    at UserService.getUserProfile (src/services/user.ts:45:12)

Timeout - Async callback was not invoked within the 5000 ms timeout

Snapshot name: `Button renders correctly 1`
Received value does not match stored snapshot

用户: 测试失败了，帮我看看

Claude: 我来看看测试失败的原因。

[读取测试输出]

失败的是 UserService.create 测试，错误是 "unique constraint violation"。
让我检查一下测试代码和数据库约束。

[读取测试文件和模型定义]

我发现问题：测试之间共享了数据库状态，上一个测试创建的用户
没有清理，导致唯一键冲突。我来修复测试的 setUp/tearDown。

Edit: tests/services/user.test.ts
...

npm run test 2>&1 | tee test-output.txt | claude -p "分析这些测试失败"

运行测试 → 发现失败 → 分析原因 → 修复代码 → 重新运行 → 验证通过
   ↑                                                        |
   └──────────────── 仍有失败 ──────────────────────────────┘

用户: 实现 calculateDiscount 函数，要求：
  - 接受价格和折扣百分比
  - 处理负值和超过 100% 的边界情况
  - 结果保留两位小数
  - 先写测试，再写实现

Claude: 好的，我按照 TDD 流程来实现。

[步骤 1] 编写失败的测试
Write: src/utils/discount.test.ts

[步骤 2] 运行测试（确认失败）
Bash: npx vitest run src/utils/discount.test.ts
→ 测试失败（函数不存在）

[步骤 3] 编写最小实现
Write: src/utils/discount.ts

[步骤 4] 重新运行测试
Bash: npx vitest run src/utils/discount.test.ts
→ 测试通过

[步骤 5] 重构
Edit: src/utils/discount.ts（优化代码可读性）

[步骤 6] 最终验证
Bash: npx vitest run src/utils/discount.test.ts
→ 全部通过

calculateDiscount 函数已实现，所有测试通过。

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hook": "npm test -- --bail --watchAll=false 2>&1 | tail -30"
      }
    ]
  }
}

{
  "hooks": {
    "Stop": [
      {
        "hook": "npm test -- --bail 2>&1 | tail -30"
      }
    ]
  }
}

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "prompt",
            "prompt": "检查是否在编写功能代码。如果是，确认对应的测试文件已存在。如果不存在，提醒先写测试。返回 'approve' 或提醒信息。"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npm test -- --passWithNoTests --watchAll=false"
            // onFailure 字段的可用性请以官方文档为准
            // https://code.claude.com/docs/en/hooks
          }
        ]
      }
    ],
    "Stop": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "npm test"
            // onFailure 字段的可用性请以官方文档为准
            // https://code.claude.com/docs/en/hooks
          }
        ]
      }
    ]
  }
}

用户: 用户报告结账时偶尔看到错误的订单总额。
问题间歇性出现，难以稳定复现。订单确认页面的
总金额与商品加税费和运费之和不符。

Claude: 我分析了结账服务的代码，发现了一个关键问题：
结账服务并行调用定价、税费和运费服务，但没有确保
它们都操作同一版本的购物车数据。如果用户在服务调用之间
修改了购物车（添加/删除商品），每个服务可能接收到不同的购物车数据。

这是典型的竞态条件（Race Condition）。

describe('checkout race condition', () => {
  test('should handle concurrent cart modifications during checkout', async () => {
    const cart = await createCartWithItems([
      { productId: 'A', price: 100 },
      { productId: 'B', price: 200 }
    ]);

    // 启动结账流程
    const checkoutPromise = checkoutService.process(cart.id);

    // 在结账过程中并发修改购物车
    await cartService.addItem(cart.id, { productId: 'C', price: 300 });

    const order = await checkoutPromise;

    // 验证订单总额基于结账开始时的购物车快照
    expect(order.total).toBe(300); // 100 + 200，不包含 C
  });
});

Claude: 解决方案是在结账开始时创建购物车的不可变快照，
然后将这个快照传递给所有后续服务调用，确保一致性。

Edit: src/services/checkout.ts
// 在结账开始时创建深度不可变快照（生产环境应使用结构化克隆或 immer 等库）
const cartSnapshot = structuredClone(cart);
Object.freeze(cartSnapshot);
// 注意：Object.freeze 是浅冻结，嵌套对象仍需递归处理

// 所有服务使用同一个快照
const [pricing, tax, shipping] = await Promise.all([
  pricingService.calculate(cartSnapshot),
  taxService.calculate(cartSnapshot),
  shippingService.calculate(cartSnapshot)
]);

用户: 应用运行一段时间后内存持续增长，最终 OOM。

Claude: 我来系统性地分析这个问题。

[步骤 1] 检查事件监听器是否未移除
[步骤 2] 检查闭包是否持有大对象引用
[步骤 3] 检查定时器是否未清理
[步骤 4] 检查缓存是否有上限

发现：UserProfile 组件在卸载时没有移除 WebSocket 监听器，
导致每个组件实例都被持续引用。

Edit: src/components/UserProfile.vue
在 onUnmounted 钩子中移除监听器。

用户: 列表页加载超过 5 秒，数据库查询慢。

Claude: 让我分析查询性能。

[步骤 1] 检查 N+1 查询问题
[步骤 2] 检查是否缺少索引
[步骤 3] 检查是否加载了不必要的关联数据

发现：ProductRepository.findAll() 对每个产品都单独查询了
分类信息，产生 N+1 问题。建议使用 JOIN 或批量查询。

Edit: src/repositories/product.ts
添加 .leftJoinAndSelect('product.category', 'category')

用户: 这个 Bug 只在生产环境出现，本地无法复现。

Claude: 让我分析日志和环境差异。

[步骤 1] 检查环境变量差异
[步骤 2] 检查数据库数据差异（边界数据、空值）
[步骤 3] 检查第三方服务行为差异
[步骤 4] 检查并发负载差异

建议：在代码中添加结构化日志，记录关键变量状态。
然后分析生产日志中的异常模式。

用户: 为 src/utils/validation.ts 编写全面的测试。
覆盖所有导出函数、边界情况和错误条件。
使用项目中已有的测试约定。

用户: 为 src/api/ 目录下的所有模块添加测试覆盖。
参考现有测试的风格。每创建一个测试文件就运行一次，确保通过。

用户: 这是购物车的产品规格：
- 用户可以添加/删除商品
- 数量更新重新计算总额
- 折扣码支持百分比或固定金额
- 税费基于配送州计算
- 满 $50 免运费

针对 CartService 类编写验证所有这些行为的测试。

用户: 给这个函数写测试

function parseDate(input: string): Date {
  const parts = input.split('-');
  return new Date(+parts[0], +parts[1] - 1, +parts[2]);
}

Claude: 我来为 parseDate 编写全面的测试。

Write: src/utils/date.test.ts

import { describe, test, expect } from 'vitest';
import { parseDate } from './date';

describe('parseDate', () => {
  test('should parse valid ISO date string', () => {
    const result = parseDate('2026-04-26');
    expect(result).toEqual(new Date(2026, 3, 26));
  });

  test('should handle month boundary (January)', () => {
    const result = parseDate('2026-01-01');
    expect(result.getMonth()).toBe(0);
  });

  test('should handle month boundary (December)', () => {
    const result = parseDate('2026-12-31');
    expect(result.getMonth()).toBe(11);
  });

  test('should handle leap year date', () => {
    const result = parseDate('2024-02-29');
    expect(result.getDate()).toBe(29);
  });

  test('should handle empty string', () => {
    expect(() => parseDate('')).toThrow();
  });

  test('should handle malformed input', () => {
    expect(() => parseDate('not-a-date')).toThrow();
  });

  test('should handle single-digit month/day', () => {
    const result = parseDate('2026-1-5');
    expect(result).toEqual(new Date(2026, 0, 5));
  });
});

      /\
     /  \      E2E 测试（少量）—— 验证完整用户旅程
    /----\
   /      \    集成测试（中等）—— 验证组件协作
  /--------\
 /          \  单元测试（大量）—— 验证业务逻辑

用户: 为 SearchBar 组件写测试，使用 React Testing Library。
测试：默认 props 渲染、用户输入触发防抖搜索、加载状态显示、
结果正确显示、空状态消息。

用户: 为 /api/orders 端点编写集成测试。
测试所有 CRUD 操作、认证要求、验证错误和分页。
使用 supertest。Mock 支付网关，但使用真实数据库。

用户: 用 Playwright 编写用户注册流程的 E2E 测试：
注册 → 邮箱验证 → 首次登录 → 新手引导。

// tests/factories/user.factory.ts
let counter = 0;

export function createUser(overrides: Partial<User> = {}): User {
  counter++;
  return {
    id: `user-${counter}`,
    email: `user${counter}@example.com`,
    name: `Test User ${counter}`,
    createdAt: new Date('2026-01-01'),
    ...overrides,
  };
}

用户: 这个请求偶尔返回 500，但错误信息不明确。
帮我在关键路径添加日志，追踪请求处理流程。

Claude: 我会在请求处理的关键节点添加结构化日志。

Edit: src/middleware/requestLogger.ts
添加：请求入口、认证结果、数据库查询前后、响应发送

Edit: src/services/orderService.ts
添加：订单创建参数、价格计算中间值、外部 API 调用结果

npm run dev 2>&1 | tee app.log | claude -p "监控并报告任何异常模式"

用户: 这个 Bug 上周还不存在，帮我找出引入它的提交。

Claude: 我来使用 git bisect 定位问题提交。

Bash: git bisect start
Bash: git bisect bad HEAD        # 当前版本有 bug
Bash: git bisect good HEAD~20  # 20 个提交前正常
Bash: git bisect run npm test -- tests/failing.test.ts

[分析结果]

问题提交是 a1b2c3d："优化查询性能"
该提交移除了一个必要的索引，导致特定查询超时。

用户: 审查这段代码，找出可能导致 Bug 的模式。

Claude: 我发现了以下潜在问题：

1. [高] 第 45 行：未处理 Promise rejection，可能导致未捕获异常
2. [中] 第 62 行：使用 == 而非 ===，类型强制可能导致意外行为
3. [中] 第 78 行：循环中修改数组长度，可能导致索引跳过
4. [低] 第 91 行：缺少输入验证，依赖调用方提供正确格式

用户: 分析这个分布式系统中的数据不一致问题。
涉及三个服务和最终一致性。

## 测试规范

### 框架
- 单元测试：Vitest
- 组件测试：React Testing Library + Vitest
- E2E 测试：Playwright
- API 测试：supertest

### 约定
- 单元测试与源码同目录（Button.test.tsx 紧邻 Button.tsx）
- E2E 测试放在 tests/e2e/
- 使用工厂函数生成测试数据（见 tests/factories/）
- 用 msw Mock 外部 API（见 tests/mocks/）
- 每个测试文件应可独立运行

### 命令
- `npm test` —— 运行所有单元测试
- `npm run test:e2e` —— 运行 Playwright 测试
- `npm run test:coverage` —— 生成覆盖率报告
- `npm run test:watch` —— watch 模式

### 覆盖率阈值
- 分支覆盖率：80%
- 语句覆盖率：85%
- CI 低于阈值则阻断 PR

### TDD 规则
1. 新功能必须先写失败的测试
2. 只写刚好能通过测试的最小代码
3. 每次绿灯后考虑重构
4. 禁止无测试的功能代码