我什么时候应该选择测试驱动开发？答案

【问题标题】：When should I opt for test driven development?我什么时候应该选择测试驱动开发？
【发布时间】：2010-06-09 19:44:20
【问题描述】：

我的问题与标题相同。我还没有进行测试驱动开发，我已经进行了单元测试，并且我知道一般的测试，但我听说遵循 TDD 是非常有利的？所以我应该每次都选择它还是有一些先决条件......我只需要知道一些基本或重要的要求，当我应该选择 TDD 时。对不起，如果这个问题太琐碎了。

【问题讨论】：

标签： tdd

【解决方案1】：

每当您为项目编码时，我都会说。我的意思是你希望在哪里生成将被人们使用的代码。除了您正在学习和发现新技术的研究之外，这基本上是所有代码。

即使您认为该项目只是一个小项目，事情也经常会在不小心的情况下失控。当您发现自己不得不重构大量代码时，您会为测试感到高兴。

还要注意，tdd 不仅仅是测试。它是一种开发方法，鼓励您创建干净和可靠的设计。

当你开始 tdd 一切。一旦你有更多的经验，那么也许你可以退后一步，确定什么时候不要 tdd。

【讨论】：

【解决方案2】：

恕我直言，如果您对 TDD 不满意，尝试将它应用到需要交互/使用遗留代码的项目中，这比从头开始在项目中应用它要复杂得多。事实上，关于这个，有一个完整的book。

HTH

【讨论】：

【解决方案3】：

我的建议是尽可能多地使用单元测试。

警告：根据我的经验，TDD 在使用您已经有一定经验的技术时效果最好。如果您不确切知道所需的结果是什么样的，通常很难编写测试断言（例如，如果您一生中从未编写过操作方法，请尝试为 ASP.NET MVC 操作方法编写测试）。在这些情况下，您最好在实现代码后编写单元测试。

【讨论】：

【解决方案4】：

如果我正在开发没有用户界面的东西，这些天我总是使用 TDD。毕竟，您必须测试软件。您可以做额外的工作并进行 TDD，或者您可以做额外的工作并将用户客户端聚集在一起进行测试。前者测试更完整，可重复性更高。

另一方面，针对用户界面代码执行 TDD 并没有真正为我带来太多价值。由于各种业务原因，我的工作仅限于 Visual Studio 开箱即用，并且使用 VS“录制”测试会耗费大量时间，尤其是当您更改 UI 时必须重新录制它们时。我为 UI 背后的业务逻辑做 TDD，而不是 UI 本身。

【讨论】：