Question

开始学习TDD并遇到一些关于编写测试的不同方法的误解。

在一些文章中，据说你应该为每个案例编写新的测试。因此，单个方法可以有两个或更多个测试。

我看到的另一种方法是在几个步骤中编写更复杂的测试。例如：写测试 - ＆gt;失败 - ＆gt;写代码 - ＆gt;成功 - ＆gt;修改当前测试（添加新断言） - ＆gt;失败 - ＆gt;写代码 - ＆gt;成功 - ＆gt;等等。完成此步骤后，测试将涵盖单个方法的整个逻辑。

使用TDD的方法的优缺点是什么？

Answer 1

将一堆断言添加到现有测试用例中“更容易”，因为您不需要创建新的测试用例（并为它们提供名称），但我更愿意编写较小的测试更具体。主要优点是，如果/当测试失败时，您将获得更好的信息。

让我们看看我是否能想出一个人为的例子：

[Fact]
public void TestEverything()
{
    var foo = new Foo();
    Assert.Equal(42, foo.TheAnswer);
    Assert.Equal(string.Empty, foo.Log);
    foo.DoSomething();
    Assert.Equal("something was done", foo.Log);
}


[Fact]
public void TheAnswer_AfterCreation_ShouldAdhereToTheHitchhikersGuide()
{
    var foo = new Foo();
    Assert.Equal(42, foo.TheAnswer);
}

[Fact]
public void Log_AfterCreation_ShouldBeEmpty()
{
    var foo = new Foo();
    Assert.Equal(string.Empty, foo.Log);
}

[Fact]
public void Log_DoSomething_ShouldLogSomething()
{
    var foo = new Foo();
    foo.DoSomething();
    Assert.Equal("something was done", foo.Log);
}

正如你所看到的，为测试方法创造好名字真的很难（我做了一个糟糕的工作，特别是对于最后一个），但只是想象如果TheAnswer_AfterCreation_ShouldAdhereToTheHitchhikersGuide失败会发生什么：你会得到一个相当不错的来自您的测试工具的描述，而不是TestEverything失败的信息（挑战：尝试为它提出一个更好的名称;-)）

简单或更复杂的测试？

1 个答案: