单元测试的成本
单元测试是一个反复出现的主题对我来说这最后几周; 关于Stackoverflow之间和其他论坛和讨论的测试,我写了两个正在进行的项目, 我问关于单元测试的实际成本的几个问题.
这是尤指由托马斯勃兰特文章 (德国: “拓展署在明镜 (我的) 实践 - 希望与现实”) 这使我深思. 勃兰特在他的文章介绍确实不错,理论与实践测试驱动开发这个海湾. 空白点, 相反,它坚持TDD的原则;
我必须首先指出,测试驱动开发, 特别是“第一次测试”的原则, 是一个相当 “性感” 发展. 也一定能提高软件的架构,并阻止我们做某些 (小) 错误.
— 相对自由的翻译有关T. 勃兰特
因此,他认为拓展署的有力工具 – 至少从纯粹的学术. 但直接的结果是一个疑问;
现在的问题是根本: 代价是什么?
如上所述, 除了T. 勃兰特和我, 很多人似乎要求, 而最常见的问题如下: 是,使用单元测试她是否真的更好的软件, 并努力投资她们现实?
简明, 这个问题归结为一个简单的:
那是我花多少单元测试?
通常,问题涉及, 谁想到,他提出了单元测试是过于昂贵,适用于持续. 我记得有一个讨论,我对测试覆盖的总价值已超出了理论的理想. 报告说,努力提供我说: “不” 当时.
截至今天,我认为这些问题都要求纯粹的魔鬼, 因为它不知道成本是重要的单元测试, 更多:
我如何支付了单元测试的遗漏?
这里是我的答案, 用一个具体的例子说明;
我目前的项目之一,包括大量的分布式组件. 我发现了一个草案中的错误, 这迫使我这两类重构. 所有我花了大约 1 小时. 发射单元测试? 关于 30 第二. 30 秒,我发现,有些行为并不像原先计划. 我花了大约20分钟的更正. 编写测试成本约45分钟我.
资产负债表是约两个小时.
如果没有单元测试, 我可能不会注意到的一些错误立即. 我将不得不 1 时间重构, 在一个或多或少确定, 当然遍布几天, 纠正问题时,改变被忽视. 这一次的概率远远超出一个小时是比较高的 (调试 “手”, 重新创建多线程应用程序等条件…).
就我而言, 我发现,在确定的时间计算 (有测试涵盖了软件的现实的一部分 – 不 100%) 更有趣的是,在黑暗中导航的实践.
实验!



