必须先在 TDD 中编写测试吗？ [关闭]答案

【问题标题】：Do test HAVE to be written first in TDD? [closed]必须先在 TDD 中编写测试吗？ [关闭]
【发布时间】：2011-08-23 18:28:51
【问题描述】：

今天早上，我与一位同事讨论了 TDD。在他看来，要真正做到 TDD，必须先编写测试，然后再编写代码。我认为，只要您的测试驱动您的代码和您根据您正在执行 TDD 的测试的反馈做出决策（例如：注入依赖项、单一职责等）。所以我认为应该区分测试优先和测试驱动。

我了解 TDD 规则，阅读过书籍、博客和敏捷论坛。到目前为止，这里的每个人都给了我关于 TDD 的书籍文本定义。

我与这个小组联系的原因是因为我们知道“解决方案不在教科书中”。另外我需要知道我不是唯一一个认为这是合理的疯子:)

是否必须先编写测试才能进行 TDD？你有什么意见？

【问题讨论】：

我认为这是programmers.stackexchange.com的问题
如果还没有试驾开发，如何开发？
@steenhulthin - 那么......我该怎么办？将其复制并粘贴到 stackexchange? 上，这是一个我从未使用过的网站，到目前为止我对它一无所知。我猜 stackoverflow 应该是所有开发问题、主题讨论的目的地。那改变了吗？下一步是什么？ Stackoverflow 付费网站？我只是想知道，所以我现在可以开始存钱了:)
如果它适合你，你可以这样做。对我来说，我喜欢具体的测试，这样我就可以将其可视化，然后“推动生产代码设计”。我不太擅长在脑子里胡思乱想。无论如何，既然你花了这么多时间思考它..为什么不在你写测试的时候写..稍后再写有什么好处？

标签： unit-testing tdd agile

【解决方案1】：

我认为重要的是它是一个迭代过程，其中迭代次数非常少。因此，如果您的第一步是创建一个文件并使用一个方法创建一个简单的类，然后编写一个调用该方法并失败的测试，那么我认为您首先创建哪个文件并不重要。你必须决定你正在创建的东西看起来像什么足以编写一个调用它的测试，谁在乎你保存文件的顺序？但是如果迭代比这大得多，那么你可能没有做 TDD。将整个类预先编写为一次大迭代绝对不能算作 TDD。

【讨论】：

完全同意你的观点，事件的顺序无关紧要。预先编写整个课程的 +1 不算作 TDD。
@Buzzer：是的，这个想法是在您编写代码时从测试中受益，它应该引导您走向可测试的设计并提供更多反馈，通过经常在代码和代码之间来回切换测试。相反，如果您确实喜欢我的一些同事并推迟编写测试，直到功能编写完成，那么编写测试将变得毫无意义。

【解决方案2】：

在纯 TDD 中，首先编写测试。如果团队有必要的纪律，我个人认为只要测试驱动开发就可以了。在测试涵盖所有功能之前，什么都不会“完成”。

【讨论】：

那你是说TDD和Refactoring不能一起做？
@buzzer 我在哪里说的？
抱歉，您没有明确表示是对的。我只是指关于“在纯 TDD 中，首先编写测试”的评论，这意味着在重构工作中，无法进行纯 TDD。我100同意你的其余陈述。
@buzzer TDD 和重构完美地结合在一起。如果您有一些代码，并且有一些测试，那么一旦您开始重构，您的测试就会（应该）中断。因此，在这种情况下，您可以 1) 更改代码然后更改测试或 2) 更改测试然后更改代码....