再思考测试策略

Question

在Plone项目上，我们的团队努力实现全面的测试覆盖，至少对于重要的产品是这样。我们编写的测试类型是单元测试、功能测试和集成测试。(也是压力测试，但不属于这个问题的范围)。目标至少有两个方面:促进升级和捕获bug(有时甚至在编写测试的过程中发生)。

然而，Plone/Zope是一个复杂的系统，经过多年的经验，我注意到，应该重新考虑测试策略。首先，单元测试(通常需要使用大量的模拟)不是那么(成本)有效的。当编写一些核心的、逻辑密集型的功能时，它们大多是容易的和有益的，比如纯Python模块，这些模块与Plone/Zope、数据库等具有可忽略不计的耦合。我很少看到单元测试捕捉任何bug，除了编写它们的时候。

因此，根据我的经验，在做通常的事情(编写视图/portlet/viewlet)时，编写功能测试和集成测试要高效得多。它的基本原理是，如果Plone/Zope发生更改(在升级过程中)，我们可以捕捉代码中的错误。视图通常没有太多的“算法”逻辑，它们将几个数据源(如目录查询)粘合在一起，可能会对模板进行一些表单处理和预处理。视图经常调用一个或多个工具来执行一些常规工作(比如获取导航树或查找站点根)。嘲笑这一切似乎不明智。例如，有时候Plone/Zope会将某些默认类型更改为另一种类型，所有那些模拟的测试都很高兴地继续工作，而代码在实际实例中失败。

功能/集成测试有时是脆弱的(HTML可以改变)，但是它们也更便宜。它们提供基本的覆盖范围，并在基础系统更改时触发警报。找出事故的根源通常不是问题。(更新:错误:发现集成测试失败的地方可能是个大问题，但我们的代码单元测试通常没有帮助。)

问题是，我是否忽略了一些重要的东西--将单元测试限制在函数和类上，这些函数和类不需要大量地模拟环境，而是“纯粹”的逻辑负担？我找不到任何理由来编写单元测试“第一”，甚至根本没有任何理由来编写Plone/Zope中的每一段代码(我指的不是系统的核心，只是我们自己为客户添加的代码)。

为了减少基于意见的问题，还有其他原因吗?我没有提到或解决上述问题，在代码严重依赖于复杂(而且有些多毛)的框架，而代码更多地充当框架子系统的粘合剂的情况下，需要考虑编写更多的单元测试(和更少的集成测试)？

Answer 1

我很少看到单元测试捕捉任何bug，除了编写它们。

这是继续编写单元测试的一个很好的理由--单元测试不仅用于回归测试，而且有助于指导系统的设计。如果单元测试可以帮助您注意到正在测试的代码中的bug，那么您就可以立即修复这些错误，这就是真正的价值所在。

视图经常调用一个或多个工具来执行一些常规工作(比如获取导航树或查找站点根)。

还有两个原因--行为验证和回归测试-- 100%肯定地知道View X确实调用了tool Y，并将结果传递给了小部件处理器，因此小部件Z没有呈现的原因，必须是小部件处理器(或其他什么)，而且您甚至不必使用调试器来修复它！

找出事故的根源通常不是问题。

一个非常有争议的，公认的主观的(我的舌头坚定地在我的脸颊！)我希望“有益”或至少“思想食物”一开始:你能定义“通常”吗？

在“不寻常”的情况下，你没有立即发现问题的根源，因为现在是凌晨2点，你的眼睛因为monitor...how的眩目而流血，你真的花了很多时间去寻找问题吗？你有没有衡量过在这些情况下你可能要花多少时间来和预先写测试来找出问题所在--如果你分析这个问题，并在TDD之前及时找到一个净收益，那么我就说这是你的底线。

当然，如果分析表明，在你的情况下，它确实不能节省你的时间，那么有一个被证明的，很好的理由不去做它-你不能输！