代码之家 › 专栏 › 技术社区 › obelix

单元测试特定值

tdd unit-testing

obelix · 技术社区 · 14 年前

bool IsSpecial(int value)
   if (value == 3)
      return true
   else
      return false

当需求发生变化并说它现在变成3并且20是特殊的时,我将编写另一个测试来验证当使用20调用此函数时是否也返回true。该测试将失败,然后我将去更新函数中的if条件。

我可能会在这里做一些严重的错误,所以任何其他技术来绕过这也是受欢迎的。

4 回复 | 直到 14 年前

Rob 14 年前

这是个好问题。正如你注意到的 Not3IsNotSpecial

在.NET环境中,您可以使用新的代码契约功能来编写测试谓词(即 后置条件 )直接在方法中。静态分析器将捕获您提出的缺陷。例如:

Contract.Ensures(value != 3 && Contract.Result<Boolean>() == false);

我认为任何一个TDD迷现在都在尝试使用契约来查看使用模式。你有工具来证明正确性的想法是非常有力的。甚至可以为接口指定这些谓词。

Model Based Testing . 这个想法类似于合同法。你设置了 不是3也不是特别的 抽象条件(例如。, IsSpecial(x => x != 3) == false) )并让模型执行环境生成具体的测试。我不确定,但我认为这些环境也可以进行静态分析。无论如何,您可以让模型执行环境针对您的SUT连续运行。我从未使用过这样的环境,但这个概念很有趣。

haydenmuhl 14 年前

不幸的是,这种特殊情况是很难防范的。对于像IsSpecial这样的函数,测试40亿个阴性测试用例是不现实的,所以,不,你没有做错什么。

这是我脑子里想的。许多存储库都有挂钩,允许您在每次签入时运行某些进程,例如运行单元测试。可以设置一个标准,即新签入的代码必须在单元测试中达到某个代码覆盖率阈值。如果提交不满足某些指标,那么它将被拒绝。

相信我,我感觉到你的痛苦。我和那些同样抵制单元测试的人一起工作。

Ankit Bansal 14 年前

现在您可以在这里检查,如果枚举中不存在值,则该测试应该失败。并为enum类编写一个测试来检查可能的值。如果添加了新的可能值,则测试将失败。

因此,您的方法将变成:

bool IsSpecial(int value)
   if (SpecialValues.has(value))
      return true
   else
      return false

您的特殊值将是一个枚举,如:

enum SpecialValues {

三(3),二十(20)

   public int value;
}

现在您应该编写测试枚举的可能值。一个简单的测试可以是检查可能值的总数,另一个测试可以是检查可能值本身

Carl Manaster 14 年前

基于业务领域的知识,20可能是一些需要测试的有效条件。基于业务问题的知识编写BDD风格的测试可能有助于您明确地理解它。
4可能是一个很好的测试值,因为它是一个边界条件。这在现实世界中可能更容易发生变化,因此更可能出现在完整的测试用例中。