在测试驱动开发中，您是先编写每个可能的测试，然后编写代码吗？

Question

在进行测试驱动开发时，我一直习惯于先为新功能编写第一个单元测试，然后编写该功能的代码。如果我有其他测试要编写以涵盖所有场景，我通常在编写代码后编写它们。这被认为是不好的形式吗？在编写代码之前，我是否应该首先尝试为一项功能编写所有可能的测试？

Answer 1

为了正确执行TDD，您始终先编写测试，然后再编写功能。

除此之外，我会一次采用一个场景，不要编写20个测试，然后编写这20个测试的代码。写一个测试，红色/绿色标记，然后继续下一个测试。这确保您也在做TDD的核心原则之一，即尽可能简单的实现，以满足您的所有需求/场景。

Answer 2

实际上没有，我经常发现“在旅途中”的功能。让我再解释一下“不”：

我通常开始为高级功能编写测试用例，定义其接口。之后，我通常将此测试设置为忽略并继续为每个接口功能编写测试。我的周期如下：

1. 故事A（高级API）的集成测试
2. 在Integration Test
中调用的方法xyz的写单元测试
3. 实施方法（红/绿/重构）
4. 重复2 + 3直到整合测试通过。

在这样做时，我经常意识到我在主测试中忘记了一些小功能。然后，我通常会花时间回顾客户的要求。如果它合适，我回去为它添加一个测试，设置为忽略，因为我首先要完成我的开始。

有时我看到有机会进行重构。我通常完成一个实现，直到我达到提交点然后进行重构，但有时我会隐藏我的更改，然后返回并首先进行重构（包括新的测试，如果有必要）。这个工作流程由Mercurial MQ提供。

Answer 3

对于大多数人来说，TDD和增量/敏捷开发是一致的。这看起来像：

1. 为某些功能编写测试
2. 编写足够的代码以使测试通过，并根据需要进行重构
3. 重复。

如果你碰巧提前有详细的规格，你可以先写下所有的测试，但你必须忍受经过一段时间没有通过的测试。

Answer 4

越早编写测试，越好。我通常认为编写测试比实际实现功能更困难，因为你必须意识到所有可能的结果。所以当我“在区域”时，我倾向于写更多的测试。在编码期间，我意识到我可能错过了一个测试用例，我只是注意到了待办事项列表。

所以在我看来，这取决于你的闲暇，但我会多次实施测试。

Answer 5

我看待它的方式，测试驱动开发不一定是测试第一次开发。您的测试可以推动您的开发，并且您在开发应用程序时正在编写测试。您首先编写一个失败的简单测试，因为您还没有编写功能。然后编写代码来实现它，以便测试通过。

然后你回到你的测试，进行修改会强制你添加更多功能或重构你的代码以遵循更好的做法或减少重复的代码，修改你的代码以使测试通过...重复，重复，重复。

以下是一些演示此内容的视频，尽管您可以通过Google搜索“TDD视频”找到更多内容

http://agilesoftwaredevelopment.com/videos/test-driven-development-basic-tutorial （oops，只有一个视频，新用户不能插入多个链接）

Answer 6

我尝试在每个功能位之前在某个级别编写测试。有时，我必须编写更多代码来通过编译器，但我尽量减少这一点。首先编写测试意味着我在编写代码之前已经考虑了代码应该实现的目标。

我认为有用的一种技巧是保存索引卡或记事本，并记下我一路上想到的所有情况。这让我可以专注于当前的任务，而不会忘记我应该考虑的所有其他事情。之后，我可以完成列表并完成额外的案例或删除它们。

Answer 7

你可以这样做，但你不会做TDD。问题（好吧，其中之一，无论如何）预先编写所有测试的是，在任何情况下，要求都是非平凡的，你的测试将构建在很多关于代码结构的假设中。重新试驾。大步骤导致失误。

TDD成功的关键之一涉及采取小步骤。小步骤意味着在出现问题时退出的更改更少。小步骤意味着您可以更频繁地了解您正在进行的更改的影响。而且因为小步骤更容易放心，它们会产生增加速度的矛盾效应。

TDD周期从需求开始。首先选择一个您知道如何通过测试立即定义的要求，只需几个小步骤。如果你看一个要求并且你不确定如何测试它，或者你认为，“是的，但要做到这一点，我需要[首先插入不明确的步骤]”，然后你应该跳到您知道该怎么做的另一个要求，或者您应该将此要求分解为您知道如何做的较小要求。

一旦你有了这个，你就会在一个简短的红绿重构循环中工作：编写一个量化需求的某些部分的测试（“红色”，因为它失败了，因为它还没有要测试的实现），写任何将通过测试的代码（“绿色”），然后重新编写代码以删除重复，幻数和其他代码气味（“重构”）。在重构阶段，您应该继续小步骤，经常重新运行测试，以确保您没有破坏任何东西。继续这个循环，直到你可以看到你的老板/客户，并满足要求。

现在您已经定义了一个简单的系统，您已经打开了可实现的要求列表 - 现在可以通过较小的步骤测试和实现与您刚刚实现的要求相邻或依赖的要求建立你已经完成的工作。

所有这一切的结果是：不要试图一次完成所有测试。一次只做一件小事。

Answer 8

TDD的要点是，当功能尚未实现时，您必须观察测试失败。所以你必须在代码之前编写测试。

Answer 9

当你进入TDD节奏时，你一次写一个测试并让它工作。非常短的红绿重构循环真的感受到了节奏。话虽这么说，其他方法没有任何问题（它们甚至可能对某些类型的问题更有意义）但通常你需要做的关于你正在考虑的其他测试的唯一事情是写下来（或者你的对如果你是结对编程写下来的话）所以你不要忘记它们。无论如何你必须这样做，因为你可能会在编写不同的测试时忘记测试。

Answer 10

进行足够的测试以一次测试1个单位的代码..然后编写实际代码，直到它通过测试。冲洗，清洗，重复直到完成。

如果你发现自己需要为一个代码单元（一个方法，一个函数等）编写许多测试，那么这可能表明你试图在那个单元中做太多...这反过来使得该单元难以测试＆amp;稍后重构。