单元测试中的多个断言

Question

我刚刚读完 Roy Osherove 的《单元测试的艺术》，我正在努力遵循他在书中提出的最佳实践。最佳实践之一是不在测试方法中使用多个断言。这条规则的原因对我来说相当清楚，但它让我想知道......

如果我有这样的方法：

public Foo MakeFoo(int x, int y, int z)
{
     Foo f = new Foo();
     f.X = x;
     f.Y = y;
     f.Z = z;

     return f;
}

我是否真的必须编写单独的单元测试来断言 Foo 的每个单独属性都使用提供的值进行初始化？在测试方法中使用多个断言真的那么不常见吗？

仅供参考：我正在使用 MSTest。

编辑：感谢您的所有回复。我想我最终会采用多个断言。在我的情况下，正在测试的行为是 MakeFoo 生成正确的 Foo。因此，断言每个属性都获得预期值就足够了。但是，如果设置其中一个属性存在条件，那么我会分别测试每个单独的结果。

但我仍然不喜欢它......我喜欢每个测试有一个断言的想法的原因是你知道测试失败的确切原因。如果你解决了问题，那么测试就会通过。对于多个断言，您没有相同的保证。如果您解决了失败断言所暗示的问题，则没有什么可以阻止测试中稍后的另一个断言接下来失败。如果断言被分开，那么您从一开始就知道这两个失败。

最后，我不只是使用 .Equals() 的原因是因为在我的情况下 Foo 是一个 LINQ-To-SQL 实体，它引入了一些不值得在这里讨论的复杂性。

再次感谢。

Answer 1

每个单元测试只测试一个概念要重要得多。

测试一个概念可能需要多个断言，因此不必过度担心断言的数量。当然，如果您最终得到大量断言，您可能需要退一步思考一下您真正在测试什么。

Answer 2

在这种情况下，如果我试图严格执行每个测试的一个断言，我将在 Foo 上断言相等，而不是在其组件上断言。这促使我编写 Foo.equals()，这本身通常是一件好事。但我并不总是严格限制每个测试的一个断言。看看什么让你感觉良好。

Answer 3

AFAI 看，实践背后的原则是

• 每次测试测试一个有凝聚力/逻辑的东西；导致简洁且易于阅读的测试。
• 以获得更好的测试隔离。一项测试不应因 n 个原因之一而失败。如果确实如此，那么如何修复它并不是立即显而易见的；没有首先调查导致失败的原因。一个单一的改变不应该让一大堆看似无关的测试失败。
• TDD 初学者规则手册中的入门规则；以便他们能够内化这个过程。

重点不是每次测试都需要一个“NUNit”/“xUnit”断言；相反，每个测试都有一个逻辑断言。

[Test]
public void MakeFoo_SeedsInstanceWithSpecifiedAttributes()
{
  Assert.AreEqual( new Foo(1,2,3), Foo.MakeFoo(1,2,3), "Objects should have been equal );
}

这里我有一个 NUnit 断言（让断言警察高兴）：但是它正在幕后测试三件事（在 Foo.Equals 中，我将检查是否所有变量是平等的。）
指导方针是防止像（即伪装成单元测试的集成测试）这样的测试。

[Test]
public void ITestEverything()
{
  // humongous setup - 15 lines
  payroll.ReleaseSalaries();
  // assert that the finance department has received a notification
  // assert employee received an email
  // assert ledgers have been updated
  // statements have been queued to the printqueue
  // etc.. etc..
}

故事的寓意：这是一个很好的目标。尝试将您想要测试的所有内容组合起来一个具有好名字的逻辑/有凝聚力的断言。例如 Assert.True(AreFooObjectsEqual(f1,f2)。如果您发现很难命名内聚验证/断言 - 也许您需要检查您的测试并看看是否需要拆分它。

Answer 4

我实际上已经编写了一个 NUnit 插件来帮助解决这个问题。尝试一下 http://www.rauchy.net/oapt

Answer 5

在测试中使用多个断言是很常见的，但我不认为这是“最佳实践”。

我想说的是，您确实想对上述函数使用多次测试，这样您就可以看到问题出在哪里。我最近一直在使用一个相当大的测试套件，其中有一些我尚未追踪到的奇怪故障，而我遇到的问题是每个测试用例都做了太多事情。我已将它们分开，现在我可以禁用失败的特定部分，以便我可以在有机会时返回它们。

但是，您仍然可以使用夹具来分析设置和拆卸的共性。我不能与 MSTest 交谈，但在 UnitTest++ 中你会做类似的事情：

class FooFixture
{
public:
   FooFixture() : f(MakeFoo(kX, kY, kZ)) { }

   static const int kX = 1;
   static const int kY = 2;
   static const int kZ = 3;

   Foo f;
};

TEST_FIXTURE(FooFixture, IsXInitializedCorrectly)
{
   CHECK_EQUAL(kX, f.X);
}

// repeat for Y and Z

这不是更多的打字，特别是考虑到剪切和粘贴。哎呀，在 vim 中，只需 esc y ctrl-{ pp 然后进行少量编辑即可。不过，通过这种设置，您可以查看是否只是一个字段出现故障，然后深入了解原因。

Answer 6

我通常发现自己在一个方法中有多个断言，但它们通常都与手头的测试相关。有时我会插入一个断言来验证我知道会破坏测试的先决条件，因为我不希望测试意外成功。

[Test] // NUnit style test.
public void SearchTypeAndInventory() 
{
    var specification = new WidgetSearchSpecification 
                    {
                        WidgetType = Widget.Screw,
                        MinimumInventory = 10
                    }; 
var widgets = WidgetRepository.GetWidgets(specification);
if( !widgets.Any() ) 
    Assert.Inconclusive("No widgets were returned.");
Assert.IsTrue( 
    widgets.All( o => o.WidgetType == Widget.Screw), 
    "Not all returned widgets had correct type");
Assert.IsTrue( 
    widgets.All( o => o.InventoryCount >= 10), 
    "Not all returned widgets had correct inventory count.");

* 虽然我可以合并断言，但我发现分离出问题的地方更有用。

---

我认为坚持每次测试 1 次断言的硬性规则不是很有用。更重要的是，测试只是测试一件事。我见过许多超级测试，它们是一种测试类的所有内容的巨大方法。这些超级测试很脆弱且难以维护。

您应该认为您的测试与它们正在测试的代码一样重要且编写良好。例如，应用相同的重构技术来确保测试只做一件事并且做得很好，而不是测试所有可见内容的烟囱。

Answer 7

按照我看书的方式，你应该做“红、绿、重构”。在“重构”部分中，您应该重构被测代码和单元测试。

我认为以下重构没有任何问题：

Original

[TestMethod]
public void TestOne()
{
    LetsDoSomeSetup();
    AssertSomething();
}

[TestMethod]
public void TestTwo()
{
    LetsDoSomeSetup(); // Same setup
    AssertSomethingElse();
}

Refactored

[TestMethod]
public void TestOneTwo()
{
    LetsDoSomeSetup();
    AssertSomething();
    AssertSomethingElse();
}

当然，假设两个断言是相关的，并且当然依赖于相同的场景。