TDD中的单元测试

Question

我对TDD很新，我想到的第一个问题是我是否应该对每个开发的组件应用单元测试。我问它，因为我发现单元测试需要花费很多时间，特别是当提供了一些需求变化时。那么，您能否就TDD中关于单元测试的最佳实践提出建议？

Answer 1

在three rules中表达的TDD简短描述：

1. 除非要通过失败的单元测试，否则不允许编写任何生产代码。
2. 您不得再编写任何单元测试，而不是足以使其失败;编译失败就是失败。
3. 您不能再编写足以通过一次失败的单元测试的生产代码。

更长的说明：http://jamesshore.com/Agile-Book/test_driven_development.html

更深入的描述：http://www.growing-object-oriented-software.com/

Answer 2

只是一个观察 - 你说

  

我观察到单元测试需要一个   很多时间

在短视图中是正确的。但是对于即将出现一段时间的代码，额外的工作可以节省时间。我强调了几年前我所在的一个项目的单元测试的价值，告诉大家会听，“我们没有时间跳过这一步。”这是真的。有很多地方可以节省时间 - 测试人员将花费更少的时间测试应用程序，通过您使用的任何错误跟踪过程来回击错误，您将花费更少的时间记住您几周或几个月后所做的事情，以便您可以修复错误，用户将看到更少的错误，这意味着他们将花更少的时间来嘲笑你破坏的应用程序。您将在凌晨2点花更少的时间在手机上，希望您可以在用户第二天来之前修复该应用。

在某种程度上，这一切都涉及到经济学。对于任何进入生产的代码，请相信我，您没有时间跳过该步骤。它会花费你更多的时间和你的公司更多的现金。

如果代码不会刺激，也就是说，它是您编写的用于帮助完成某项任务的实用程序，或者看看网络层是如何工作的，那么您需要根据需要调整执行的测试量。经验将有助于指导您了解正确数量。

Answer 3

TDD意味着测试推动了组件的开发。首先编写一个指定组件行为的单元测试，然后实现该组件。所以回答你的问题：

  

应该对每个人进行单元测试   开发的组件

不，因为在开发组件之前应该已经编写了单元测试。

Answer 4

测试推动了代码的开发。 TDD实际上是关于定义软件的期望行为，事实上它是可测试的只是一个很好的副作用。

有关TDD的优秀论文here