【发布时间】：2011-03-14 05:54:02
【问题描述】：
我对 TDD 很陌生，我想到的第一个问题是我是否应该对每个开发的组件应用单元测试。我之所以问它，是因为我观察到单元测试需要很多时间，尤其是在提供了对需求的一些更改时。那么，您能否就单元测试提出类似 TDD 中的最佳实践之类的建议？
【问题讨论】：
-
我不确定这是什么问题。您能否详细说明并提出更具体的问题？
标签： tdd
【发布时间】：2011-03-14 05:54:02
【问题描述】：
用three rules表示的TDD的简短描述：
- 您不得编写任何生产代码，除非是为了通过失败的单元测试。
- 不允许您编写任何足以导致失败的单元测试；编译失败就是失败。
- 您编写的生产代码不得超过足以通过一个失败的单元测试的数量。
还有更详细的描述：http://jamesshore.com/Agile-Book/test_driven_development.html
【讨论】：
只是一个观察 - 你说
我观察到单元测试需要 很多时间
这在短期内是正确的。但是对于需要一段时间的代码，额外的工作可以节省时间。我在大约几年前参与的一个项目中强调了单元测试的价值，并告诉所有愿意倾听的人，“我们没有时间跳过这一步。”这是真的。有很多地方可以节省时间 - 测试人员将花费更少的时间来测试应用程序，通过您使用的任何错误跟踪过程将错误踢回，您将花费更少的时间记住几周或几个月后所做的事情，以便您可以修复错误，用户会看到更少的错误，这意味着他们会花更少的时间对你的应用程序大喊大叫。您将在凌晨 2 点花更少的时间在手机上，希望您能在用户第二天到来之前修复应用程序。
在某种程度上，这一切都与经济学有关。对于要投入生产的任何代码，相信我，您没有时间跳过该步骤。这将花费您更多的时间和您的公司更多的现金。
如果代码不会产生影响，也就是说，它是您编写的用于帮助完成某些任务的实用程序，或者查看网络层的实际工作方式，您需要调整测试量以满足需要。经验将帮助您了解正确的数量。
【讨论】：
-
所有测试都需要很长时间。 TDD 很明显。编写后进行测试使其不那么明显。
TDD 意味着测试推动组件的开发。您首先编写一个指定组件行为的单元测试，然后实现该组件。所以回答你的问题：
应该对每一个应用单元测试 开发组件
不，因为单元测试应该在开发组件之前就已经编写好了。
【讨论】：
测试推动代码的开发。 TDD 实际上就是定义你的软件的期望行为，事实上它都是可测试的，这只是一个很好的副作用。
一篇关于 TDD 的好文章可在here
【讨论】：