代码之家 › 专栏 › 技术社区 › Finglas

TDD-一次测试一次还是批量?

tdd unit-testing

Finglas · 技术社区 · 15 年前

对于单元测试,您应该:

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

或

写下所有已知的测试。制作一个通过。重构。

我这样问是因为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...
    }
}

8 回复 | 直到 15 年前

Chris Johnston 15 年前

编写足够的测试以使测试失败,通常这是因为代码没有编译
编写足够的代码来通过测试
重复

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

TDD的要点不是编写测试,而是使用测试来驱动设计。其思想是,一旦您的所有测试都通过了,并且它们涵盖了所有的功能,您就知道您的代码也是完整的。没有测试,你怎么知道你什么时候完成。所以,当你觉得你已经测试了所有的东西,停下来。

JB King 15 年前

我会投票给第一个 YAGNI 想到为什么第二个测试会有问题,因为这可能需要很长的时间来首先编写所有的测试。

philant 15 年前

我先编写一个测试,然后让它通过,然后重构。

通过一次测试,我可以专注于测试所展示的能力。

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

// test_foo_with_negative_value(void)

然后我拿起一个,实现了它…我可以选择最简单的一个,进行中,或者完全不同的一个,看看我的设计是否可以处理这种情况。

Tyler Carter 15 年前

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

这种方法有许多有益于开发过程的原因:

易于调试
一次只关注一个想法,不太复杂
它使用自下而上的方法,允许小的东西形成一个更大的产品。

Jason Irwin 15 年前

第一个。它将帮助您更好地理解当前正在实现的功能,因为您必须考虑您要测试的内容。如果你同时做所有的事情,这将是太多的认知开销!

Frozenskys 15 年前

一次一个,用于TDD。

编写一个测试-编写代码以通过该测试,清洗并重复,直到所有测试都通过。一旦测试用完,就重构代码。

Rhys Jones 15 年前

就我个人而言,我发现一次只写一个测试可以帮助我专注于我正在研究的特性,而不是一次尝试一批测试。我更喜欢单个测试的节奏/流程,它有助于避免 特征蠕变 在一个测试中编写多个测试时可能会引入这种方法。

digiarnie 15 年前

在一个完美的开发团队中(换言之:in 我的完美的开发团队),我将结对编程,一个人是测试人员,一个人是生产代码开发人员。测试人员将为生产代码逻辑编写一个简单的测试,而生产代码开发人员将编写 最简单的 满足测试的东西。一旦完成,双方都会签入他们的代码。然后重构测试和生产代码。然后办理登机手续。然后继续测试。

测试->生产代码->签入->重构->签入->重复