考虑单元测试字典对象.您可能编写的第一个单元测试只是将一些项添加到字典中并检查异常.下一个测试可能类似于测试计数是否准确,或者字典返回正确的键或值列表.
但是,后面这些情况中的每一个都要求字典可以首先可靠地添加项目.如果添加项目的测试失败,我们不知道我们后来的测试是否因为他们正在测试的内容不正确而失败,或者因为我们可以可靠地添加项目的假设是不正确的.
我是否可以声明一组单元测试,如果其中任何一个测试失败,导致给定的单元测试是不确定的?如果没有,我应该如何最好地解决这个问题?我是否错误地设置了我的单元测试,以至于我遇到了这种困境?
这并不像看起来那么难。让我们稍微改一下这个问题:
如果我测试一段需要工作的代码
System.Collections.Generic.List<T>.Add,当有一天微软决定中断时我该怎么.Add办List<T>?我是否会根据此进行测试以获得不确定的结果?
上述问题的答案是显而易见的;你不知道。你让它们失败的原因很简单——你的假设失败了,测试也应该失败。这里也是一样。一旦你的 add 测试开始工作,从那时起你就假设 add 可以工作了。您不应以与第三方测试代码不同的方式对待您的测试代码。一旦它被证明有效,你就会认为它确实有效。
另一方面,您可以利用称为保护断言的概念。在删除测试中,在排列阶段之后,您引入了额外的断言阶段,该阶段验证您的初始假设(在本例中 - 添加正在工作)。有关此技术的更多信息可以在此处找到。
为了添加一个示例,NUnit 使用上面以Theory名称伪装的概念。这正是您所提议的(但它似乎与数据驱动测试而不是通用实用程序更相关):
该理论本身负责确保提供的所有数据都满足其假设。它通过使用 Assume.That(...) 构造来完成此操作,该构造的工作方式与 Assert.That(...) 类似,但不会导致失败。如果特定测试用例不满足假设,则该用例返回Inconclusive 结果,而不是 Success 或 Failure。
然而,我认为马克·西曼在回答我所链接的问题时所说的最有意义:
对于给定的测试用例,可能需要满足许多先决条件,因此您可能需要多个 Guard Assertion。不必在所有测试中重复这些测试,而是为每个先决条件进行一个(且仅一个)测试,可以使您的测试代码更易于维护,因为这样可以减少重复。
| 归档时间: |
|
| 查看次数: |
231 次 |
| 最近记录: |