我目前正在研究一个已经生产了两年以上的项目。该项目广泛使用单元测试和脚本化UI测试。初始单元测试涵盖了系统框架，业务规则和状态转换（或工作流程）。测试脚本用于黑盒测试。然而，随着时间的推移，维护我们全套单元测试的成本变得越来越昂贵，特别是与国家有关的成本。何时使用测试脚本进行单元测试？
有点调查后，我们发现，测试脚本更有效（即，提供更好的覆盖），并且更便宜的维护与比对工作流程的单元测试。这并不是说单元测试的价值已经被完全否定，但是它确实引发了这个问题，即某些类型的单元测试是否可以被放弃以支持测试脚本。
我们的项目是在一个迭代增量模型运行。
一对这样回答的“单元测试的限制”的问题是，当它被用来测试任何与整合，而不是功能的单元测试变得错综复杂。连接和使用外部服务（数据库，SSH到另一台服务器等）和用户界面是两个例子。
这并不是说你不能使用单元测试这些东西，它只是参与覆盖所有基地的难度使得使用这种测试方法不值得，除非在可靠性是最重要的案件。
我用我所有的自定义JavaScript UI代码“脚本测试”（模板引擎，效果和动画等），我发现它快速，可靠的，如果做的权利。
您通常使用单元测试来做到这一点：测试单元。更确切地说，测试一个单元是否符合其接口规范/合同。如果单元测试失败，您确切地知道问题出在哪里：它在被测单元内。这使得调试变得更容易，尤其是因为单元测试的结果可以自动处理。自动回归测试在这里浮现。
如果您要离开单元测试的范围或想要测试单元测试无法很好测试的东西，那么您就开始使用脚本化的UI测试。例如。当你测试与许多你无法模拟的外部API接口的代码时。现在，您可以挑起某些错误，但要追查失败埋在代码中的确切位置要困难得多。
实际上，有四个级别的测试，其中3个可能涉及脚本，第一个没有。
功能域示例：服务层总线，即所有能够在总线上公开其服务的项目（通常封装一些核心参照数据库）。
你可以这样做：
如上所述，最后3种测试可能会涉及重型脚本，并可能很快覆盖更多的代码。根据单元测试的类/方法的数量，良好的汇编测试可能是更好的方法。
通过更多的方式，我已经体验到了与单元测试相同的痛苦，特别是在那些成员对单元测试并不热衷的项目中，他们中的很多人只是忽略或评论-out测试能够欺骗源代码管理，节省时间等。一位前同事甚至为此创造了“截止期驱动开发”一词。
在我看来面临这种挑战时，下面是一些指导方针面对面的人的单元测试：
这就是说，我仍然认为单元测试不应该完全丢弃。测试脚本和单元测试有其自己的目的。但是，在维护TDD的过度热忱尝试和面对企业应用程序开发的现实之间应该取得平衡。
我的假设是，单元测试的维护工作量会增加，因为您的应用程序的体系结构可能会崩溃。由于除了你以外，没有人知道你的代码中有什么，所以你可能需要应用这五种方法来确定你真正的根本问题是什么。只要您采用高度分离的基于接口的体系结构，IME单元测试永远不会维护成本高昂。
一般而言，单元测试必须改变以反映新的业务需求，但在某些情况下，更改会影响系统的许多方面，更新所有受影响的单元测试的影响非常高。在这种情况下，测试脚本已经被证明比单元测试更便宜。 – 2008-09-23 09:26:29
你应该非常害怕对单元测试产生如此影响的变化。单元测试现在可能为自己付出代价，帮助你发现和理解你所引入的变化。 – slim 2008-09-23 11:03:57