Question

让我们想象一下，我们需要开发一个只显示当地室外温度的应用程序。所以，当你使用TDD时，你会写一个测试用例：

describe 'App'
  it 'shows the local temperature'

那就是它。一周之后，你意识到人们会因为看到完整的当地天气预报而付费，所以你继续TDD：

describe 'App'
  it 'shows the local temperature'
  describe 'when they pay me 5$'
    it 'shows full weather forecast'

但是，有些人建议添加阴性测试以避免误报：

describe 'App'
  it 'shows the local temperature'
  it 'does not show full weather forecast'
    describe 'when they pay me 5$'
      it 'shows full weather forecast'

// or even

describe 'App'
  it 'shows the local temperature'
    describe 'when scrooge'
      it 'does not show full weather forecast'
    describe 'when they pay me 5$'
      it 'shows full weather forecast'

虽然会阻止意外地让付费用户无法看到完整的天气预报，但这并不是真正可扩展的（例如，我们有很多接入层）。

问题是：是否有任何众所周知或已建立的做法可以平衡TDD中的假阳性检测？

Answer 1

简短的回答是否定。只是为了给你一些背景信息，这一切都归结为负面测试的要求的重要性。在您给出的示例中，如果对于用户来说防止意外允许不付费以查看全天候预测很重要，那么您会考虑添加（TDD）否定测试。

然而，通常使用TDD，您首先编写一个积极的测试，为“快乐路径”场景构建您的软件。这样你就可以得到一个可用的软件。 TDD就是关于小型设计。

然后，如果要求在负面情景下是关键的，那么您可以考虑稍后添加它们。这可能是一旦软件处于测试阶段，您可能会发现某些负面测试至关重要。因此，您可以根据需要开始添加它们。记住要有一个思维模式，你只需要在绝对需要时添加它们。

Answer 2

但是，有些人建议添加一个否定测试以避免错误阳性：

它不会避免误报。当应用程序没有真正显示温度时，误报为it 'shows the local temperature'。

正如Spock指出的那样，系统地添加负面测试（测试不会发生事件的测试）是有问题的，因为可以通过这种方式测试的东西没有尽头。

我经常写回归测试来查找在现实中确实发生的错误，但很少有机会检查那些可能以多种模糊方式出错的错误。

Answer 3

另一种思维方式是将该功能重新定义为“当且仅当用户付费时，该应用才显示全天候”。

如果用一种方法或两种方法测试，那就是品味问题。像这样的伪代码：

userSeesFullWeatherOnMainPageIfAndOnlyHeHasPaid: freeUser = aNewUser() freeUser.getsMainPage() freeUser.shallNotSeeFullWeather() paidUser = aNewUser() paidUser.paysForFullWeather() paidUser.getsMainPage() paidUser.shallSeeFullWeather()

如何在TDD中找到负面测试的余额？

3 个答案: