在开发过程中创建单元测试对开发时间以及维护活动所花费的时间有什么影响？

我是一名顾问，我将向客户现场的所有开发人员介绍单元测试。我的目标是确保所有新应用程序都应对所有创建的类进行单元测试。

客户端因修复其现有应用程序中的错误而存在高维护成本的问题。他们的应用程序的寿命介于5到15年之间，在此期间，他们不断添加新功能。我非常有信心，他们将从单元测试开始中受益匪浅。

我对单元测试对开发时间和成本的影响感兴趣：

• 作为开发过程的一部分，编写单元测试会增加多少时间？
• 通过良好的单元测试，可以节省多少维护活动（测试和调试）时间？

与仅编码相比，在开发过程中创建单元测试时需要多少时间才能开发出应用程序？

关于此有一些非常有趣的研究。阅读以下白皮书：

通过测试驱动的开发实现质量改进：四个工业团队的成果和经验

本文讨论了白皮书及其作者之一Nachi Nagappan的其他研究：http : //research.microsoft.com/zh-cn/news/features/nagappan-100609.aspx

该研究及其结果发表在题为“通过测试驱动的开发实现质量改进：四个工业团队的结果和经验”的论文中，由Nagappan和IBM Almaden研究中心的研究同事E. Michael Maximilien撰写；微软首席软件开发主管Thirumalesh Bhat；和北卡罗莱纳州立大学的Laurie Williams。研究团队发现，TDD团队在缺陷密度方面的代码比非TDD团队提高了60％至90％。他们还发现，TDD团队花了更长的时间才能完成他们的项目-延长了15％至35％。

Nagappan说：“在12个月的开发周期中，还有35％是另外四个月，这是巨大的。” “但是，权衡是要减少代码发布后的维护成本，因为代码质量要好得多。同样，这些是管理者必须做出的决定-他们应该在哪里受到打击？但是现在，他们实际上已经量化了做出这些决定的数据。”

另外，Jason Gorman在今年的Software Craftsmanship会议上提出了这样的实验。他一直在尝试使用TDD和非TDD方法创建相同应用程序的实验，最近他在博客上发表了有关其结果的博客：

经过3次迭代，完成没有TDD的kata所需的平均时间为28m 40s。TDD的平均时间为25m 27s。没有TDD的情况下，我平均通过5.7（通过了接受测试）。使用TDD时，我平均获得1.3次通过（两次尝试是他们第一次通过，一次经历了2次通过。）

当然，这是一个婴儿实验。也不完全是实验室条件。但是我注意到一些有趣的事情，都是一样的。

当更多的人进行实验时，看到该实验的全部结果将很有趣。

有没有可用的统计数据显示进行（良好）单元测试时维护减少了多少小时？

从上面的白皮书中：

案例研究的结果表明，与未使用TDD做法的类似项目相比，四种产品的预发布缺陷密度降低了40％至90％。