何时使用测试脚本而不是单元测试？答案

【问题标题】：When to use test scripts over unit testing?何时使用测试脚本而不是单元测试？
【发布时间】：2008-09-23 08:58:14
【问题描述】：

我目前正在从事一个已经投入生产两年多的项目。该项目广泛使用单元测试和脚本化 UI 测试。最初的单元测试涵盖了系统框架、业务规则和状态转换（或工作流程）。测试脚本用于黑盒测试。然而，随着时间的推移，维护我们全套单元测试的成本变得越来越昂贵，尤其是那些与状态相关的测试。

经过一番调查，我们发现测试脚本比与工作流相关的单元测试更有效（即提供更好的覆盖率）并且维护成本更低。这并不是说单元测试的价值已被完全否定，但它确实提出了这个问题，是否可以放弃某些类别的单元测试以支持测试脚本。

我们的项目在迭代增量模型上运行。

【问题讨论】：

【解决方案1】：

在很多方面，我都经历过与单元测试相同的痛苦，尤其是在成员对单元测试完全不热情而且他们中的许多人只是忽略或评论的项目中-测试能够欺骗源代码控制，节省时间等。一位前同事甚至为此创造了“截止日期驱动开发”一词。

在我看来，当面对这种挑战时，以下是针对单元测试的一些指导方针：

丢弃过时的测试 - 有时如果它们本质上不准确或不相关，尝试更新数百到数千行测试是没有意义的。立即放弃测试。不要“忽略”它们，不要将它们注释掉。完全删除它们。
为新功能编写测试 - 任何新功能仍需要进行单元测试并以可单元测试的方式编写。
为错误修复编写测试 - 在对应用程序进行回归测试时，可能需要确保错误修复具有确保错误已得到修复的单元测试。
代码覆盖率该死 - 我敢肯定，这可能会赢得一些反对意见，但 there is a fine line between ensuring functionality and using tests as an excuse to delay work。重点应放在确保核心功能上，而不是遵循任意代码覆盖率。

话虽如此，我仍然认为不应该完全放弃单元测试。测试脚本和单元测试有自己的用途。但是应该在过度热衷于维护 TDD 和面对企业应用程序开发的现实之间取得平衡。

【讨论】：

【解决方案2】：

关于“单元测试的局限性”问题的答案之一是，当单元测试用于测试与集成而不是功能有关的任何事情时，它会变得令人费解。连接和使用外部服务（数据库、SSH'ing 到另一台服务器等）和用户界面是使用的两个示例。

并不是说你不能对这些事情使用单元测试，只是因为覆盖所有基础所涉及的困难使得使用这种测试方法不值得，除非在可靠性至关重要的情况下。

我对所有自定义 JavaScript UI 代码（模板引擎、效果和动画等）都使用“脚本测试”，如果操作正确，我发现它既快速又可靠。

【讨论】：

【解决方案3】：

您通常使用单元测试来执行此操作：测试单元。更准确地说，测试一个单元是否符合其接口规范/合同。如果单元测试失败，你就知道问题出在哪里：它在被测试的单元内。这使得调试更容易，特别是因为单元测试的结果可以自动处理。这里想到了自动回归测试。

如果您想要离开单元测试的范围，或者想要测试无法通过单元测试很好地测试的东西，那么您可以开始使用脚本化 UI 测试。例如。当您测试与许多无法模拟的外部 API 接口的代码时。现在您可以引发某些错误，但要准确跟踪代码中隐藏故障的位置要困难得多。

【讨论】：

这个问题更适用于现有单元测试数量较多的大型系统。在某些情况下，新需求对单元测试的影响比对测试脚本的影响更大。在理想情况下，我会更新所有单元测试，但实际上这样做代价高昂。

【解决方案4】：

实际上有四个级别的测试，其中3个可能涉及脚本，第一个不涉及。

功能域示例：服务层总线，即所有项目（通常封装一些核心参考数据库）都能够在总线上公开其服务。
你可以这样做：

如前所述，最后 3 种测试可能涉及繁重的脚本编写，并且可以快速覆盖更多代码。根据要进行单元测试的类/方法的数量，一个好的汇编测试可能是更好的方法。

【讨论】：

【解决方案5】：

两种不同的东西

这两个类别应该是不同的，并且都扮演着同样重要的角色。放弃一个并不是好兆头。您提到的测试脚本属于第二类。为此，我会推荐 FIT / Fitnesse 之类的东西。如果那不可行，那么测试脚本/记录重播风格的工具。但是不要扔掉好的单元测试。'维护测试的成本变得昂贵'是什么意思？

【讨论】：

一般来说，单元测试必须改变以反映新的业务需求，但在某些情况下，改变会跨越我们系统的许多方面，并且更新所有受影响的单元测试的影响非常大。在这种情况下，测试脚本被证明比单元测试更便宜。
您应该非常害怕对单元测试产生如此影响的更改。通过帮助您发现和理解您引入的更改，单元测试现在可能正在为自己付出代价。
这可能有点像线程死灵法......但仅仅因为某些东西不是“单元测试”并不意味着它是一个验收测试。验证代码是否正确有很多层，从单元层一直到整个系统装配在一起。我在工作场所使用外部测试脚本，它们肯定只是验证代码是否正确，而不是验证是否开发了正确的代码。

【解决方案6】：

我的假设是，您的单元测试的维护工作会增加，因为您的应用程序架构被允许分崩离析。由于除了您之外没有人真正知道您的代码中有什么，您可能需要应用五个为什么方法来确定您真正的、基本的、根本问题是什么。只要您采用高度解耦、基于接口的架构，IME 单元测试的维护成本就不会很高。

【讨论】：