如何在TDD中平衡负面测试的编写？

好问题！在TDD里平衡负面测试的核心思路其实很简单：跟着风险、需求和潜在的假阳性问题走，绝对不是为了凑测试数量而写。咱们结合你举的天气应用例子来拆解：

先回顾你的初始TDD测试脉络 #

你最开始聚焦核心功能的正向测试，这完全符合TDD的“先让功能跑通”原则：

describe 'App'
  it 'shows the local temperature'
end

后来扩展付费功能时，也先覆盖了正向场景：

describe 'App'
  it 'shows the local temperature'
end

describe 'when they pay me $5'
  it 'shows full weather forecast'
end

什么时候该加负面测试？ #

有人提到要加负面测试避免假阳性，这个点非常关键——如果只测“付费后能看完整预报”，万一你的代码逻辑漏了权限判断（比如不管付没付都返回完整数据），测试依然会通过，但实际是个bug，这就是假阳性。所以加负面测试的核心目的，就是堵住这类逻辑漏洞，同时覆盖用户可能遇到的异常场景。

1. 必须加的高风险负面测试（直接避免假阳性+保障业务规则）

这些场景直接影响业务逻辑和用户体验，属于TDD里“补全规则”的必要环节：

• 未付费用户尝试查看完整预报时，必须被限制（不能偷偷显示，也不能崩溃）

  describe 'when they haven\'t paid'
    it 'does NOT show full weather forecast'
    it 'shows a clear prompt to pay $5 for full access'
  end
  

• 支付未成功（比如超时、金额不足、支付失败）的用户，不能获得权限

  describe 'when payment fails (e.g., insufficient funds or timeout)'
    it 'retains only basic temperature access'
    it 'shows a payment failure notification'
  end
  

2. 可灵活选择的负面测试（看团队严谨度）

这类场景属于边缘情况，对业务影响不大，但如果团队追求极致严谨可以补充：

• 支付金额不是$5（比如$4、$10）时，不能解锁完整预报

  describe 'when they pay an amount other than $5'
    it 'does NOT unlock full weather forecast'
    it 'informs user the exact required amount is $5'
  end
  

3. 完全没必要加的负面测试（别浪费时间）

那些违背常识、几乎不可能发生，或者不属于当前测试范围的场景，完全可以跳过：

• 用户输入负数金额会不会解锁功能？（除非你的支付系统真的允许负数，否则没必要）
• 用户篡改本地存储假装付费能不能看预报？（这属于后端安全校验范畴，前端测试不用管）

总结平衡的核心原则 #

1. 先正向，后负面：TDD的核心是先让功能正常工作，所以先写正向测试验证核心流程，再补负面测试堵漏洞。
2. 只测有风险的场景：负面测试不是越多越好，只关注那些会导致假阳性、破坏业务规则、让用户困惑的场景。
3. 和需求对齐：如果需求里明确说了“只有付费用户能看完整预报”，那“未付费不能看”就是必须测的；如果需求没提边缘金额的情况，暂时可以不用测，等后续有需求再补。

内容的提问来源于stack exchange，提问作者igorpavlov