TDD - 一次测试还是批量测试? [英] TDD - One test at a time or make a batch?

问题描述

对于单元测试，你应该；

For unit tests should you;

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

Write a test. Write code to pass it. Refactor.

或

编写所有已知的测试.做一个经过.重构.

Write all your known tests. Make one pass. Refactor.

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

I ask this because TDD states you stop writing code after all tests pass but this point is unclear.

编辑

我认为 TDD 更关注这一规则"的一件事与故事/任务有关，不是吗?有人同意吗?

One thing I think TDD focuses on more for this "rule" is in relation to stories/tasks no? Does anyone agree?

几个月后

在看到有关该主题的截屏视频(我会尝试找到链接)后，我进入的例行程序如下.

A routine I've gotten into after seeing a screencast (I'll try and find the link) on the subject is as follows.

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

使用 C# 的示例，但是应该足够通用.

Example using C#, should be generic enough however.

// 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...
    }
}

推荐答案

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

这些是 TDD 的规则.这意味着您一次只编写一个单元测试和一小段代码，并以迭代方式执行此操作.

These are the rules of TDD. This means that you are only ever writing one unit test and one bit of code at a time and doing this iteratively.

TDD 的重点不是编写测试，而是使用您的测试来推动设计.这个想法是，一旦您的所有测试都通过并且它们涵盖了所有功能，您就知道您的代码也已完成.没有测试，你怎么知道什么时候完成.所以，当你觉得你已经测试了一切时，停下来.

The point of TDD is not writing tests, it is using your tests to drive out the design. The idea is that once all your tests pass and they cover all the functionality you know that your code is also complete. Without tests, how do you know when you are done. So, when you feel that you have tested everything, stop.

这篇关于TDD - 一次测试还是批量测试?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！