在引用涉及 TDD 的项目/任务的估算时是否有任何指导方针？
例如，与需要 1 天才能完成的任务的正常开发相比，TDD 驱动的任务应该多花多少时间？多 50% 的时间还是多 70% 的时间？假设开发人员精通语言和测试框架，是否有任何可用的统计数据？
问问题
1007 次
5 回答
4
根据我的经验，编写测试所花费的时间与开发时间一样多，有时甚至更多（即多花费 100% 到 150% 的时间），但大大减少了修复错误所花费的时间。这里有一些关于测试驱动开发的研究。也看看这篇论文。
于 2010-04-28T23:32:27.233 回答
2
一开始差异很大，随着经验而减少，但可能始终是一个因素
随着开发人员在 TDD 方面变得更好，传统编码和 TDD 之间的实现时间差异将减小。TDD 初学者，甚至中级者，可能会忙于决定要编写哪些测试和/或将编写更多测试，这些测试最终在重构后被丢弃。有了经验，TDD'er 将变得更有效率，因为他们在选择要编写的测试方面变得更好更快
我不确定常规与 TDD 比率的绝对下限是多少。我猜是 1:1.5，但我无法相信大多数开发人员能够像编写代码一样快地测试代码，更不用说编写代码然后编写测试了。
正如其他人所说，花费在 TDD 上的额外时间的显着回报是，测试驱动代码的调试时间大大减少。
于 2010-04-29T12:37:15.340 回答
1
编码时间应该与无测试开发大致相同。调试时间应减少约 99%。
于 2010-04-28T22:56:58.127 回答
0
如果您想要一个数学答案，我的发现是花费在测试上的时间：生产是 2:1（保守的 - 花费在测试上的大部分时间是思考时间）。但是，您不能对当前（非 TDD）估计值应用 3X 因子，因为 TDD 可以帮助您取得稳定的进展.. 您不会花时间
- 编码你不需要的东西
- 在中断和修复的圈子中运行。或破坏现有功能。
- 最后是一个独特的错误发现和修复阶段
- 几乎为零的附加调试器和逐步会话
在我的脑海中，我会在你现有的估计上选择 2 倍。
于 2012-06-04T06:10:00.713 回答
0
使用 TDD 生成代码的另一个好处是编写的测试变成了回归套件。然后测试使这些活动更加安全：
- 事后重构。
- 进一步开发相同的代码。
- 错误修复。
（注意错误修复，我记得有几次我忘记实现几个案例，或者规范中有后期添加，额外的开发只是在适当的测试中轻而易举。）
于 2010-05-01T17:21:51.713 回答