单元测试中分步断言的价值

Question

在编写单元测试时，有时可以为每个可能失败的条件创建断言，也可以为捕获所有这些条件的断言创建断言。C#示例：

Dictionary<string, string> dict = LoadDictionary();
// Optional Asserts:
Assert.IsNotNull(dict, "LoadDictionary() returned null");
Assert.IsTrue(dict.Count > 0, "Dictionary is empty");
Assert.IsTrue(dict.ContainsKey("ExpectedKey"), "'ExpectedKey' not in dictionary");
// Condition actually interested in testing:
Assert.IsTrue(dict["ExpectedKey"] == "ExpectedValue", "'ExpectedKey' is present but value is not 'ExpectedValue'");

在这种情况下，添加“可选断言”对大型多人项目有价值吗？这涉及到更多的工作(如果你有很多单元测试)，但是问题出在哪里会更清楚。

我使用的是VS2010和集成的测试工具，但这个问题是通用的。

Answer 1

我认为做这样的事情是有价值的，但你必须小心如何使用它。我也在一个大型的多人项目中工作，最近我们开始在我们的单元测试策略中使用类似的方法。

我们尝试让每个“执行路径”有一个测试，并且我们有多个断言的测试用例。但是，我们在测试用例中使用致命和非致命断言，并且在具有多个断言的测试用例中只使用非致命断言。致命断言也用在这些测试用例中(每个TC一个)来验证条件，如果失败，就没有必要再断言其他任何东西了。这种方法可以帮助我们更快地定位错误，因为有时可能会出现多个断言。

将其与自定义日志相结合，以提供有关故障的附加信息-测试和调试速度更快，实际上效率更高。

然而，看看你的例子，我不确定“多个/可选断言”是不是真的很好，因为你很可能不想一遍又一遍地测试这些基本功能(LoadDict()，而不是空等)。我认为在您的例子中，“测试用例设置”应该确保Dictionary是“非空的”，并且LoadDictionary()按照预期执行(已经使用特定的TC进行了测试)。这个测试用例的目标似乎是验证查找方法，它应该只专注于测试该方法。其他一切都是设置/其他功能，不应该属于这个TC，真的。

Answer 2

建议每个测试只有一个断言，这样，您就可以清楚地知道您正在测试的是什么。

• 在测试驱动程序中，这将使在测试失败后准确隔离要实现的内容变得更容易。
• 测试工具生成的报告将更加准确。

在我看来，这些“可选的”断言都是单独的测试，但没有必要在每个测试中都断言它们。

• 测试LoadDictionary();是否返回null，
• 测试LoadDictionary();是否返回空null

不要让一个测试包含所有这些断言。绝对不会有几个测试包含大多数断言，然后是每个测试要检查的实际内容。

Answer 3

就我个人而言，我认为先发制人地重新访问现有测试以插入可选断言没有太大价值。

如果这是一个现有的项目，希望您的所有测试都能通过。如果是这样的话，只有在重构和/或更改或添加代码时，它们才会开始崩溃。

我认为，如果测试失败，那么处理这些测试会更容易。当然，您的测试将会出现一般性的失败，但是通过抛出断点(或者通常只是调查)，您将非常容易地发现失败的真正原因。

或者，当测试失败时，您可以添加可选的断言，然后澄清错误。这样，您就不会使用预先的时间来向不会失败的测试添加额外的断言，但当您这样做时，您仍然可以获得好处。

然而，如果这是一个主动的举动(如您所建议的)，概述了测试的指导方针，我认为这真的取决于测试本身以及您从附加断言中获得的好处。通过知道dict为空而不是仅仅丢失一个键，您将真正节省多少时间？归根结底，你应该只测试一件事，所以如果你在一次测试中发现了很多断言，那可能是出了什么问题。

就我个人而言，我不认为规定所需断言的全球政策是值得实施的。我认为这应该根据具体情况来决定。对于某些测试，比如您给出的例子，一些额外的断言可能有很大的价值。对于不太可能失败的更简单的东西，可能没有。

强迫开发人员捕获和描述每个可能的离散故障有点负面。就像你期望它足够频繁地失败，所以值得花几分钟来诊断它。