使用 TDD 进行项目实施估算
在引用涉及 TDD 的项目/任务的估算时是否有任何指导原则？
例如，与正常开发需要 1 天才能完成的任务相比，TDD 驱动的任务需要多花多少时间？多花 50% 的时间还是多花 70% 的时间？假设开发人员精通该语言和测试框架，是否有任何可用的统计数据？
Are there any guidelines when quoting estimates for projects/tasks involving TDD?
For example, when compared to normal development of a task taking 1 day to complete, how much more should a TDD driven task take? 50% more time or 70% more time? Are there any statistics available, assuming the developer is well versed with the language and the test framework?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
根据我的经验，编写测试需要与开发一样多的时间，有时甚至更多的时间（即增加 100% 到 150% 的时间），但会大大减少修复错误所花费的时间。以下是一些测试驱动开发研究。另请参阅本文。
To my experience, writing tests takes as much time and sometimes even more time than development (i.e. add from 100% to 150% more time) but drastically reduce the time spent for bug fixing. Here are some Studies Of Test Driven Development. Also have a look at this paper.
这种差异一开始很大，随着经验的增加而减小，但可能始终是一个因素
。随着开发人员在 TDD 方面变得更好，传统编码和 TDD 之间的实现时间差异将会减小。 TDD 初学者，甚至中级人员，可能会陷入决定要编写哪些测试的困境，和/或会编写更多在重构后最终被丢弃的测试。随着经验的积累，TDD 人员将变得更加高效，因为他们在选择要编写的测试方面变得更好更快，
我不确定传统测试与 TDD 比率的绝对下限是多少。我猜是 1:1.5，但我不敢相信大多数开发人员能够像编写代码一样快速地测试驱动代码，更不用说先编写代码然后编写测试了。
正如其他人所说，花费额外时间进行 TDD 的显着回报是测试驱动代码的调试时间大大减少。
The difference is high at first, decreases with experience, but is probably always a factor
The difference in implementation time between conventional coding and TDD will decline as the developer becomes better at TDD. TDD beginners, and even intermediates, are likely to get caught-up deciding what tests to write and/or will write more tests that end up being thrown out after refactoring. With experience, a TDD'er will become more efficient, as they become better and quicker at choosing what tests to write
I'm not sure what the absolute lower limit of the ratio of conventional to TDD is. I'd guess 1:1.5, but I can't believe that most developers can ever test-drive code as fast as they could just write code, much less write code then write tests.
And as others have said, a significant payoff for that extra time spent doing TDD is that debugging time is vastly reduced for test-driven code.
编码时间应该与无测试开发大致相同。调试时间应减少约 99%。
Coding time should be about the same as testless development. Debugging time should be reduced by approximately 99%.
使用 TDD 生成代码时的另一个好处是编写的测试成为回归套件。然后，测试使这些活动更加安全：
（注意错误修复，我记得有几次，要么我忘记实现几个案例，要么对规范进行了较晚的添加，额外的开发在适当的测试下是轻而易举的。）
Another payoff when producing code with TDD is that the tests written become a regression suite. The tests then make these activities much more safe:
(NB wrt Bug Fixing, I remember a couple of times where either I'd forgotten to implement a couple of cases or there were late additions to the spec, the additional development was a doddle with tests in place.)
如果你想要一个数学答案，我的发现是测试所花费的时间：生产是 2:1（保守 - 测试所花费的大部分时间是思考时间）。但是，您不能将 3 倍因子应用于当前（非 TDD）估计，因为 TDD 可以帮助您取得稳定的进展。您不会花时间
我突然想到，我会在您现有的估计的基础上选择 2 倍。
If you want a mathematical answer, my finding has been has been time spent in test : production is 2:1 (conservative - majority of time spent in test is THINK time). However you can't apply a 3X factor to your current (non-TDD) estimates because TDD helps you make steady progress.. you don't spend time
Off the top of my head, I'd go for a 2X on your existing estimates.