单元测试 - 实用性：全部或大部分时间是否通过？

Question

这是一个关于单元测试的哲学问题，从实用性的角度来看：测试用例是应该全部还是大部分时间通过或失败？

情侣点：

1. 如果您正在练习TDD，预计单元测试最初会失败。点是你开始开发 https://en.wikipedia.org/wiki/Test-driven_development

2. 如果单元测试一直失败并且软件仍然投入生产 - 它只是意味着开发人员无法修复测试用例，或测试用例无关紧要/无用。

3. 如果单元测试一直失败并且软件 NOT 已发布到生产中 - 这意味着开发人员在生产启动之前仍有工作要做。

4. 如果单元测试从未失败，这也表明测试用例无用？ 但是，这让我想起了“泰坦尼克号”：）

我提到实用性 - 测试用例也需要时间/资源来开发。编写太多无用的测试是没有意义的。世界不是“测试驱动”。这是商业/资金驱动的。

Answer 1

如果单元测试失败，则表明某些内容无效：被测系统（SUT）无法正常工作，或者单元测试无效。

如果单元测试无效，则应修复或删除。

如果SUT无法正常工作，则表示您的系统存在缺陷。在这种情况下，您的最高优先级应该是解决缺陷。

每次办理登机手续时，所有测试都应通过。

当您执行TDD时，您最初会看到测试失败，并且the reason you can trust them。但是，作为TDD red / green / refactor 循环的一部分，在每次迭代结束时，您应该进行全绿色测试运行。这就是重点。

因此，测试应该在大部分时间内通过。

Answer 2

我认为你的困惑源于对TDD过程的误解。大部分时间100％的测试都应该通过。当您将代码提交到版本控制时，它们应该通过。当你重构你的代码时，它们应该通过。当你发布你的代码时，它们绝对应该通过。

典型的TDD是：

1. 创建新测试

2. 看到它（只有它）失败

3. 编写代码以使其通过

4. 看到它传递（和所有其他传递）。如果没有转到第3步

5. 根据需要重构

有时，集成或意外更改会导致其他测试失败。但这应该立即解决或恢复。这不是被忽视和稍后评估的东西。