哪种类型的单元测试在业务价值上回报最多？

Question

我的问题假设人们已经相信某种类型的单元测试是值得的，并且实际上是在他们当前的项目中编写它们。我们还假设代码的某些部分的单元测试不值得编写，因为它们测试的是微不足道的功能。例如getter/setter和/或编译器/解释器会立即捕获的内容。相反的假设是“有趣的”代码是值得测试的。

Answer 1

代码区域的覆盖级别应该与更改的可能性和依赖于它的功能数量的组合成正比。

例如，我们在基本控制类的核心有一些相当复杂的解析逻辑。我们对它进行单元测试，因为它必须处理来自我们影响之外的系统的输入(更改的可能性很高)+我们所有的UI控件都依赖于它才能稳定。基础中的最小调整都会通过继承层和依赖层产生涟漪和放大效应。

Answer 2

验证层之间传递的数据的单元测试通常会增加最大的价值

界面<->业务数据<->

Answer 3

我发现最有回报的测试是测试之前发现的bug。在我看来，如果一个团队除了在修复错误时添加回归测试之外什么都不做，他们将比几乎任何其他测试策略获得更多的回报。

通过测试已损坏的内容(并对其进行彻底测试)，您知道您正在测试的是易损坏的区域。

当然，这假设您正在测试在开发过程中中断的东西，而不是仅仅等待QA报告在部署或类似的事情之后陆续出现。