单元/功能测试是否应该假设未测试的应用程序部分运行正常？

Question

我是测试驱动开发的新手，但我正在开发一个新应用程序。我已经创建了一些基本功能，但认为这可能是开始使用测试驱动开发的好机会。我正在使用此基本大纲编写测试要求以涵盖主要功能（感谢wikipedia）：

1. 设置
2. 执行
3. 验证
4. 清理

然后，当我开始编写测试代码时，我将遵循以下工作流程：

1. 添加测试
2. 运行所有测试并验证新测试是否失败
3. 编写代码以使新测试通过（快速/肮脏，技术债务在这里很好）
4. 运行所有测试并验证所有通过
5. 重构代码以反映最佳实践、更易于维护等。

我了解测试应该相互独立，但是在为应用程序的特定功能 (B) 编写测试时，当该功能依赖于应用程序的不同功能 (A) 的功能时，就会出现问题由不同的测试覆盖。功能 B 的测试假设功能 A 的功能是可操作的是否合适？还是手动执行功能 A 在功能 B 测试的测试代码中执行的任何步骤会更好？当功能 A 中存在错误时会发生什么？这会破坏这两个测试，并且可能会导致关于问题所在的一些歧义。对我来说，正确的选择似乎是不允许功能 B 测试运行功能 A，但我可能最终会在功能 B 测试代码中复制功能 A 代码。否则测试代码可能会变得太大或无法维护。

Answer 1

如果您在开发过程中使用 TDD，则需要考虑两个不同的“运行测试”用例。

在进行重构时，您通常并不关心在验证重构时有多少测试失败。如果测试计数为零，那么您继续；如果测试计数不为零，那么您可以放弃更改，确认您回到通过状态，然后更加小心地尝试再次进行更改。

当您合并时，事情会变得更有趣；我们现在有 许多 个候选更改，可以解释测试失败的原因。在这种情况下，精确的测试失败会有所帮助。

如果 A 是可测试的（从某种意义上说，包括 A 的实际实现并不违反我们对测试快速、可靠、确定性等的其他担忧之一）且稳定（不经常更改），那么投资赔率通常倾向于在测试中使用它。

当 A 不稳定时——尤其是在 A 的可观察行为不稳定的情况下——那么我们可能需要考虑将 B 的测试与这种不稳定隔离开来的技术。

这里最常见的两种方法是 (a) 使用稳定的替换/测试替身来代替 A 所扮演的角色，或者 (b) 在我们创建将要使用的表达式时使用真正的 A评估 B。

考虑这个简单的例子

A(x):
  return 2 * x

B(y):
  if y:
    return A(7)
  // ...

如果 A 是稳定的，我们可以在编写测试时忽略它作为实现细节

assert 14 == B(true)

但描述相同行为的等效方式是使用 A 的语言。

assert A(7) == B(true)

读取：B(true) 返回的值与 A(7)

有用的阅读：James Shore 的Testing Without Mocks。

Answer 2

至少有两种方法可以做到这一点。

1. 如您所说，为依赖于功能 (A) 的功能 (B) 编写测试。当测试运行并执行 (B) 的一部分时，它也会使用 (A)。
2. 或者为依赖于模拟 (A) 的功能 (B) 编写测试。因为您的测试是非常细粒度的，所以您将确切知道将使用 (A) 的哪个部分以及调用 (A) 的返回值是什么。当 (A) 是一个难以设置的大型组件，但您只会使用其中的一小部分时，模拟会更有用。

当功能 (A) 中存在错误时，您对 (A) 的测试会发现它，尽管在发生这种情况时可能很难解释测试失败。