我的问题假设人们已经相信某种单元测试是值得的,并且实际上是在他们当前的项目上写下来的.我们还假设代码的某些部分的单元测试不值得写,因为它们正在测试琐碎的功能.示例是getter/setter,和/或编译器/解释器将立即捕获的内容.相反的假设是"有趣的"代码值得测试.
代码区域的覆盖水平应与变化可能性和依赖于它的功能量的组合成正比.
例如,我们在基本控件类的核心部署了一些相当复杂的解析逻辑.我们对它的绝对小便进行了单元测试,因为它必须处理来自我们影响之外的系统的输入(更改的可能性很高)+我们所有的UI控件都依赖于它的稳定性.基础中最微小的调整涟漪,并通过继承和依赖的层次放大.
京公网安备 11010802040832号 | 京ICP备19059560号-6 