TDD - 一次一个测试或批量生产？

Question

对于单元测试，你应该;

  

写一个测试。编写代码来传递它。   重构。

或者

  

编写所有已知测试。做一个   通过。重构。

我问这是因为TDD声明你在所有测试通过后都停止编写代码，但这一点还不清楚。

修改

我认为TDD更关注这个“规则”的一点是与故事/任务有关吗？有人同意吗？

几个月后

我看到关于这个主题的截屏视频（我会尝试找到链接）后进入的例程如下。

• 在...处写下测试/行为/功能的名称 测试类的顶部。
• 剪切并粘贴测试名称。
• 完成测试。
• 重复直到列表为空。

使用C＃的示例应该是通用的。

// Login page should not allow blank password    // This would be removed when cut/pasted.
// Login page should not allow blank username
...

[TestFixture]
class LoginPageTests {

    [Test]
    public login_page_should_not_allow_blank_password() {
        // Test code...
    }
}

Answer 1

• 编写足够的测试以使测试失败，通常这是因为您的代码无法编译
• 编写足够的代码以使测试通过
• 重复

这些是TDD的规则。这意味着您只需要一次编写一个单元测试和一个代码，并迭代地执行此操作。

TDD的重点不在于编写测试，它正在使用您的测试来驱逐设计。我们的想法是，一旦您的所有测试都通过并且它们涵盖了您知道代码也完整的所有功能。没有测试，你怎么知道你什么时候完成。所以，当你觉得你已经测试过所有东西时，请停下来。

Answer 2

我会投票给第一个，YAGNI会想到为什么第二个可能会有问题，因为可能需要很长时间才能完成所有测试。

Answer 3

我首先编写一个测试，然后通过，然后重构。

通过单次测试，我可以专注于测试所展示的功能。

当我对下一个测试有几个想法时，我会将其作为测试占位符和/或注释编写，例如：

// test_foo_with_negative_value(void)

然后我拿起一个，实现它......我可以选择最简单的一个，进步，或完全不同的一个，看看我的设计是否可以处理如案例。

Answer 4

通常，您希望一次开发一个测试。在科学设置中，您可以隔离一个变量并对该变量进行测试。这同样适用于编程。首先，解决一个问题，然后扩展到其他问题。

这种方法有很多原因有利于开发过程：

1. 易于调试
2. 一次关注一个想法，而不是真的很复杂
3. 它使用自下而上的方法，允许较小的东西构建到更大的产品。

Answer 5

就我个人而言，我发现一次只编写一个测试可以帮助我专注于我正在研究的功能，而不是试图同时敲击一批测试。我更喜欢单个测试的节奏/流程，它有助于避免在一个测试中编写大量测试时可能引入的任何特征蠕变。

Answer 6

第一个。它将帮助您更好地了解您当前正在实施的功能，因为您必须考虑您要测试的内容。如果你一次性完成所有这将是太多的认知开销！

Answer 7

一次一个TDD。

编写测试 - 编写代码以通过该测试，冲洗并重复直到所有测试通过。一旦你用完了测试，就重构你的代码。

Answer 8

在一个完美的开发团队中（重新定义：在我的完美的开发团队中），我将与一个人作为测试人员进行结对编程，一个人是生产代码开发人员。测试人员会为生产代码逻辑编写一个简单的测试，生产代码开发人员会编写最简单的东西来满足测试要求。完成后，双方都会检查他们的代码。然后重构测试和生产代码。然后检查。然后继续测试。

测试 - ＆gt;生产代码 - ＆gt;入住 - ＆gt;重构 - ＆gt;入住 - ＆gt;重复