unit-testing - 当测试特定条件/场景时,是否需要检查之前和之后的结果?

标签 unit-testing tdd

我正在对代码进行单元测试,该代码处理将时间敏感的任务委派给可用时间可变的临时工的问题。然而,我所追求的一般答案应该独立于这种上下文。

因此,我将进行遵循以下结构的测试:

测试任务 1 在特定条件 X 下委托(delegate)给​​ Bob:

  1. 检查任务 1 是否已委托(delegate)给 Frank
  2. 创建特定条件 X
  3. 现在将测试任务 1 委托(delegate)给Bob

我的问题是,第 1 步是多余的吗?我已经有另一个单独检查步骤 1 的测试(在没有特定条件的情况下,任务会委托(delegate)给 Frank)。

但是,添加步骤 1 让我确信我的测试实际上测试的是完全正确的东西 - 我验证结果在条件 X 下会发生变化。

这是另一个更具体的示例:

如果无人可用,则不会委派测试任务

  1. 创建空闲时间并检查委派任务
  2. 删除空闲时间,并检查任务是否未委派

再说一遍,第 1 步是否太过分了?我已经有一个测试来单独测试步骤 1:

如果人员有空,测试任务就会被委派

  1. 创建空闲时间并检查委派任务

那么,重新测试上一个示例中的场景,只是为了更加确定,是不是很愚蠢?

我最初(不久前)认为这是一个好主意,但现在阅读我的代码,这似乎有点矫枉过正。但在从我的测试套件中删除一大堆代码之前我想确定一下!

谢谢!

最佳答案

对于这两个示例,我不会将第一步描述为附加测试,它们断言先决条件。如果测试的前提条件对读者来说并不明显,那么这些确实会增加值(value)。这可能是以下情况:

  • 测试的编写方式意味着对于读者来说,这个前提条件应该成立才能使测试的其余部分有效,这一点并不明显。在这种情况下,前置条件断言有助于使读者更清楚预期的前置条件。可能发生这种情况的一种情况是,如果您的测试数据是在设置方法内设置的,因为数据设置和测试声明之间的分离使读者更难理解测试的工作原理。

    <
  • 您正在处理高度复杂的代码(即复杂的数学算法),其复杂性意味着可能需要一段时间来调试测试失败并了解问题的原因。在这些情况下,断言前提条件可以极大地帮助理解测试的预期行为。

当然,除了提高可读性之外,您还可以获得这样的好处:如果测试由于先决条件而失败,那么您将更容易理解测试失败的原因。但是,我不会仅仅因为这个原因就开始向测试添加前置条件 - 如果您需要前置条件断言只是为了帮助您理解测试失败的原因,则可能是因为您的测试过于复杂.

我要补充的一件事是,如果您以这种方式使用断言语句,我只需在它们上面添加一条注释,以使读者清楚地知道您正在使用此断言来检查前提条件。

最后一点 - 这个答案仅关注单元测试。当您进入不同类型的测试(例如,执行整个软件堆栈的系统测试)时,测试可能会更加脆弱,因此在测试中包含前置条件断言的论点就会变得更强。

关于unit-testing - 当测试特定条件/场景时,是否需要检查之前和之后的结果?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/23509792/

相关文章:

Swift TDD 和异步 URLSession - 如何测试?

c# - 如何处理 TDD 中的接口(interface)过度使用?

java - 如何使用JUnit4测试void方法?

r - 正式单元测试比只编写大量示例的优势?

c# - 如何测试调用数据库的方法

android - 如何在 Android Studio 中设置全局工作目录?

unit-testing - 使用 Mockery 和 PHPUnit 模拟类的常量和方法

c# - TDD 和模拟 TcpClient

ruby-on-rails - 使用嵌套资源和关联的 FactoryGirl 对象的 Controller 的 RSpec 测试失败

c# - 测试除一个特定组合之外的所有参数组合