API 测试各种边界情况

边界情况总是被忽略

大多数 API 测试只覆盖「正常流程」。

用户输入正确的数据。服务器返回预期的响应。一切运行良好。

但现实世界不是这样的。用户会发送空字符串。网络会突然断开。数据库会返回异常数量的记录。

边界情况是系统的真实测试。它们暴露设计的缺陷。它们揭示假设的脆弱。

为什么边界情况重要

边界情况不是异常。它们是常态的一部分。

一个空数组不是错误。它是有效的数据结构。一个超长的字符串不是攻击。它可能只是用户的真实输入。

系统需要处理这些情况。不是因为它们罕见，而是因为它们不可避免。

当你跳过边界情况测试，你不是在节省时间。你是在积累债务。这个债务总会在生产环境中暴露。

边界情况的类型

边界情况不是无限的。它们遵循模式。

测试边界情况的思维方式

边界情况测试不是清单。它是一种思维方式。

问自己：这个函数假设了什么？

如果它假设数组不为空，测试空数组。 如果它假设字符串是 ASCII，测试 Unicode。 如果它假设网络稳定，模拟超时。

每个假设都是一个潜在的边界情况。

实践中的边界测试

好的边界测试有几个特征。

它是独立的。 每个测试只验证一个边界情况。不要在一个测试中混合多个边界。

它是可重复的。 无论运行多少次，结果都相同。边界情况测试不应依赖外部状态。

它是有意义的。 测试真实可能发生的边界，而不是理论上的极端情况。

// ❌ 不好的测试：混合多个边界
test('handles edge cases', () => {
  expect(api.create(null)).toThrow()
  expect(api.create('')).toThrow()
  expect(api.create([])).toThrow()
})

// ✅ 好的测试：每个边界独立
test('rejects null input', () => {
  expect(() => api.create(null))
    .toThrow('Input cannot be null')
})

test('rejects empty string', () => {
  expect(() => api.create(''))
    .toThrow('Input cannot be empty')
})

test('handles empty array gracefully', () => {
  const result = api.batchCreate([])
  expect(result).toEqual([])
})

边界情况揭示设计问题

边界情况测试不只是防御性编程。它是设计反馈。

当一个函数难以测试边界情况，通常说明设计有问题。

过多的 if-else 处理边界？可能需要重新思考函数职责。 边界情况需要复杂的 mock？可能耦合度太高。 边界测试代码比实现还长？可能逻辑过于复杂。

边界情况是系统的镜子。它反映设计的清晰度。

最后

边界情况测试不是为了达到 100% 覆盖率。

它是为了理解系统在什么情况下会失败。

理解失败比追求完美更重要。因为所有系统都会失败。唯一的区别是，你是否知道它会在哪里失败。

边界情况测试让失败变得可预测。可预测的失败可以被处理。可以被监控。可以被修复。

这就是边界情况测试的价值。

参考资源