我目前正在开展一项已投入生产两年多的项目。该项目广泛使用单元测试和脚本UI测试。最初的单元测试涵盖了系统框架，业务规则和状态转换（或工作流）。测试脚本用于黑盒测试。然而，随着时间的推移，维持我们全套单元测试的成本变得越来越昂贵，特别是那些与州相关的成本。
经过一番调查后，我们发现测试脚本更有效（即提供更好的覆盖率），并且维护成本低于与工作流相关的单元测试。这并不是说单元测试的价值已被完全否定，但它确实提出了这个问题，是否可以放弃某些类别的单元测试以支持测试脚本。
我们的项目是在迭代增量模型上运行的。
答案 0 :(得分：11)
在很多方面，我遇到了与单元测试相同的痛苦，特别是在成员对单元测试并不热衷的项目中，其中许多人只是忽略或评论 - 测试能够欺骗源代码控制，节省时间等。一位前同事甚至为此创造了“截止日期驱动开发”一词。
在我看来，面对这种挑战时，以下是一些与单元测试相关的指导原则：
话虽如此，我仍然认为单元测试不应该完全丢弃。测试脚本和单元测试有其自己的用途。但是，应该在过度热心的维护TDD和面对企业应用程序开发的现实之间取得平衡。
答案 1 :(得分：6)
关于“单元测试的局限性”问题的答案之一是单元测试在用于测试与INTEGRATION而不是功能有关的任何事情时变得复杂。连接和使用外部服务（数据库，SSH到另一台服务器等）和用户界面是使用的两个例子。
并不是说你不能对这些东西使用单元测试，只是覆盖所有基础所涉及的困难使得使用这种测试方法不值得，除非在可靠性至关重要的情况下。
我对所有自定义JavaScript UI代码（模板引擎，效果和动画等）使用“脚本测试”，如果做得对，我发现它快速可靠。
答案 2 :(得分：3)
您通常使用单元测试来完成此操作：测试单元。更准确地说，测试一个单元是否符合其接口规范/合同。如果单元测试失败，您就会确切地知道问题所在：它位于测试单元内。这使得调试更容易，特别是因为可以自动处理单元测试的结果。这里会想到自动回归测试。
如果您想要离开单元测试的范围，或者想要测试无法通过单元测试进行测试的内容，则可以开始使用脚本化UI测试。例如。当您测试与许多无法模拟的外部API接口的代码时。现在你可能会引发某些错误，但是跟踪故障埋藏在代码中的确切位置要困难得多。
答案 3 :(得分：2)
实际上，有四个级别的测试，其中3个可能涉及脚本，第一个没有。
功能域示例：服务层总线，即所有项目（通常封装一些核心参考数据库）能够在总线上公开其服务。
你可能会这样做：
如上所述，最后3种测试可能涉及繁重的脚本，并且可以快速覆盖更多代码。根据单元测试的类/方法的绝对数量，良好的装配测试可能是更好的方法。
答案 4 :(得分：1)
两件不同的事情
这两个类别应该是截然不同的，并且都起着同样重要的作用。放弃一个类别并不是好兆头。您提到的测试脚本属于第二类。为此，我建议使用FIT / Fitnesse之类的内容。如果这不可行，那么测试脚本/记录重放样式工具。但是不要丢掉好的单元测试。你的意思是“保持测试的成本变得昂贵”是什么意思？
答案 5 :(得分：0)
我的假设是单元测试的维护工作量会增加，因为应用程序的体系结构可能会崩溃。因为没有人，但你真的知道你的代码中有什么，你可能想要应用五个为什么方法来决定你真正的，必要的根本问题是什么。只要您采用高度去耦，基于接口的架构，IME单元测试的维护成本绝不会很高。