何时使用测试脚本而非单元测试？

我目前正在研究一个已经生产了两年多的项目.该项目广泛使用单元测试和脚本UI测试.最初的单元测试涵盖了系统框架,业务规则和状态转换(或工作流).测试脚本用于黑盒测试.然而,随着时间的推移,维持我们全套单元测试的成本变得越来越昂贵,特别是那些与国家相关的成本.

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

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

在很多方面,我遇到了与单元测试相同的痛苦,特别是在成员对单元测试并不热衷的项目中,他们中的许多人只是忽略或评论测试能够欺骗源代码控制,节省时间等.一位前同事甚至为此创造了"截止日期驱动开发"这一术语.

在我看来,面对这种挑战时,以下是一些与单元测试相关的指导原则:

放弃过时的测试 - 如果它们实际上是不准确或不相关的,那么尝试更新数百到数千行测试是没有意义的.立即丢弃测试.不要"忽略"他们,不要评论他们.完全删除它们.

编写新功能的测试 - 任何新功能仍需要进行单元测试并以可单元测试的方式编写.

编写错误修复测试 - 在对应用程序进行回归测试时,确保错误修复具有确保错误已修复的单元测试可能是相关的.

对于代码覆盖的地狱 - 这可能会获得一些downvotes,我敢肯定,但在确保功能和使用测试作为延迟工作的借口之间有一个很好的界限.重点应放在确保核心功能上,而不是遵循任意代码覆盖百分比.

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

关于"单元测试的局限性"问题的SO的答案之一是单元测试在用于测试与INTEGRATION而不是功能有关的任何事情时变得复杂.连接和使用外部服务(数据库,SSH到另一台服务器等)和用户界面是使用的两个例子.

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

我对所有自定义JavaScript UI代码(模板引擎,效果和动画等)使用"脚本测试",如果做得对,我发现它快速可靠.