AI 辅助编程边界：Copilot 如何编写测试用例

现在，如果我们直接告诉 AI：'为这个文件写测试'，会发生什么？

2. 初级实验：AI 能写出'Happy Path'吗？

'Happy Path'（快乐路径）指的是测试用例中最理想、最常见的流程，比如'用户付了钱，系统返回成功'。

Prompt: // Write unit tests for processPayment function using Jest

Copilot (or similar AI) 生成的代码：

// paymentService.test.ts
import { processPayment } from './paymentService';

describe('processPayment', () => {
  // 测试正常的正向流程
  it('should return success for valid payment', () => {
    const request = {
      userId: 'user_123',
      amount: 100,
      currency: 'USD',
    };
    const result = processPayment(request);
    expect(result.success).toBe(true);
    expect(result.transactionId).toBeDefined();
  });

  // 测试金额为 0 的情况
  it('should fail when amount is zero', () => {
    const request = {
      userId: 'user_123',
      amount: 0,
      currency: 'USD',
    };
    const result = processPayment(request);
    expect(result.success).toBe(false);
    expect(result.error).toBe('Invalid amount');
  });
});

分析： 这是标准的'模板式'测试。AI 完美地识别了代码中的两个 if 分支，并生成了对应的断言。这是 Copilot 最擅长的地方，它本质上是在做'模式匹配'。

但是，这引出了我们的第一个疑问：如果我们不告诉它需要测试'负数金额'，它会主动写吗？通常不会。这暴露了 AI 的第一个盲区：被动响应，而非主动发现缺陷。

3. 进阶实验：Mocking 与 外部依赖

在真实的项目中，你的函数通常不是独立的，它会调用数据库、调用第三方 API（Stripe, PayPal 等）。测试必须将这些外部依赖 Mock（模拟） 掉。这才是考验 AI 逻辑理解能力的地方。

让我们修改代码，引入一个真实的异步外部调用。

// database.ts (模拟数据库)
export const saveTransaction = async (data: any) => {
  // 这里连接了真实的数据库
  return { id: 'db_123', ...data };
};

// orderService.ts
import { saveTransaction } from './database';

export const createOrder = async (items: string[], userId: string) => {
  if (!items.length) throw new Error('Cart is empty');
  const order = { items, userId, createdAt: new Date() };
  const saved = await saveTransaction(order);
  return saved;
};

Prompt: // Write tests for createOrder and mock the database module

AI 生成的代码：

// orderService.test.ts
import { createOrder } from './orderService';
import { saveTransaction } from './database';

// 关键步骤：Mocking
jest.mock('./database', () => ({
  saveTransaction: jest.fn(),
}));

describe('createOrder', () => {
  it('should save order to database', async () => {
    // Arrange
    const mockSave = saveTransaction as jest.Mock;
    mockSave.mockResolvedValue({ id: 'mock_id' });

    // Act
    const result = await createOrder(['item1'], 'user_1');

    // Assert
    expect(mockSave).toHaveBeenCalled();
    expect(result.id).toBe('mock_id');
  });

  it('should throw error if cart is empty', async () => {
    await expect(createOrder([], 'user_1')).rejects.toThrow('Cart is empty');
  });
});

评判： 这一波操作非常漂亮。AI 不仅自动生成了 jest.mock，还正确处理了异步函数 (async/await)。这说明在基于上下文的单元测试场景下，AI 已经达到了相当高的可用性。

但是，精彩的地方来了。如果我们稍微修改一下业务逻辑，增加一个边界条件，AI 的表现会如何？

4. 陷阱与幻觉：AI 写测试时犯的那些错

AI 并不真正'理解'代码，它只是根据统计学预测最可能的下一段文本。这导致它在处理边界值和特定业务规则时，会产生令人啼笑皆非的'幻觉测试'。

案例 A：永远不会错的测试

假设我们有一段非常糟糕的代码（或者 AI 根本看不懂的混淆代码）：

// weirdLogic.ts
export const getStatus = (code: number) => {
  if (code > 100) return 'OK';
  return 'ERROR';
};

如果你让 AI 测试它，AI 会根据代码生成：

it('should return OK for code > 100', () => {
  expect(getStatus(101)).toBe('OK');
});

这看起来没问题。但是，如果产品需求变了，实际上业务规则应该是 code >= 100（大于等于）呢？AI 不会质疑代码，它会忠实且错误地测试错误的代码。这就是所谓的 '测试覆盖了代码，但验证了错误'。

案例 B：永远跑不通的断言

有时候，AI 会写出看似合理，但运行时永远无法通过的断言。

Prompt: // Test that the array contains unique elements

假设我们的原始数组是 [1, 2, 3, 3]（有重复），AI 可能会生成这样的测试：

it('should contain only unique elements', () => {
  // 假设这里返回了 [1, 2, 3, 3]
  const result = getData();
  const unique = new Set(result);
  // AI 的幻觉：它假设 Set 后长度等于原始长度
  expect(unique.size).toBe(result.length);
});

如果你运行这个测试，它会 Fail。但开发者看到 Fail 后，往往会去改代码（试图让数组没有重复），而不是意识到这个测试用例本身是基于错误的假设（数据源本身可能有重复，这不是一个 Bug，而是一个业务事实）。AI 制造了新的'伪 Bug'。

案例 C：复杂集成测试的无力

在端到端（E2E）测试或者集成测试中，AI 的表现会指数级下降。因为这需要 AI 理解状态（State）。

想象一下，你需要测试：'用户登录 -> 添加购物车 -> 点击结算 -> 验证库存扣减 -> 验证支付回调 -> 验证数据库订单状态'。

这种长达 10 步的流程，AI 很难一次性生成完整的 Flow。除非你在极其细粒度的 Prompt 中，详细描述每一步的数据库状态和预期结果。

5. 人机协作：重新定义测试工作流

既然 AI 不是万能的，那么最佳的策略就是利用 AI 的吞吐量，配合人类的判断力。在这个流程中，AI 不再是执行者，而是协作者。

AI 负责第一层的覆盖（Happy path + 基本的 Mock），而人类负责最深层的逻辑校验。

实践技巧：如何高效地让 AI 写测试？

1. 不要只说'写测试'。
   • ❌ // write tests
   • ✅ // Write unit tests for this function, specifically testing the error handling when input is null and the currency conversion logic for USD to EUR.
2. 指定测试框架。 明确告诉它用什么工具（例如 Jest, Mocha, PyTest），它能生成更精准的脚手架。
3. 让它扮演 QA 工程师。 使用 Prompt: Act as a QA engineer. What edge cases should I test for this login function? (扮演 QA 工程师，我应该测试这个登录函数的哪些边界情况？)。通常它会列出一堆你没想到的 negative case，比如 SQL 注入测试、并发登录测试等。

6. 展望未来：AI 会取代测试工程师吗？

目前的 AI，包括 Copilot，在测试领域的定位应该是 '高级助理'，而不是'独立工作者'。

AI 目前的强项：

• 生成样板代码（Boilerplate）。
• 编写针对确定逻辑的单元测试。
• 批量生成 Mock 代码。
• 将代码转化为测试（如果你有一段代码，它能帮你写测试）。

AI 目前的弱项：

• 理解真实的业务意图（Context）。
• 编写性能测试和压力测试。
• 维护测试（当代码重构后，测试需要同步更新，AI 往往会照着旧代码生成新的错误测试）。
• 探索性测试（Exploratory Testing）。

结论是：Copilot 能把测试的门槛降低，但无法把测试的质量拉高。 质量取决于人类对业务的理解深度。

最后，推荐大家在使用 AI 辅助编程时，配合阅读一下官方的最佳实践，比如 Jest 官方文档 中关于异步测试的章节，或者 MDN Web Docs 上关于单元测试的基础概念。

让我们拥抱变化，利用工具，但永远保持怀疑精神。毕竟，代码可能会说谎，但测试不能。