在单元测试中断言设置和前置条件答案

【问题标题】：Asserting set up and pre-conditions in Unit Tests在单元测试中断言设置和前置条件
【发布时间】：2010-08-31 12:52:53
【问题描述】：

每次测试有多个断言是否真的很糟糕？我通常尝试遵循“安排、行动、断言”模式以及每个测试指南中的单个断言。我认为拥有干净、小型、独立的测试是非常棒的。在大多数情况下，我设法做到了这一点。然而，有时我发现自己在安排之后就断言“先决条件”：

'arrange:
'pre-conditions:     
     Assert the arrange worked
'act:
'assert:

我的测试测试太多了吗？它是否关心它不应该关心的事情？我很想听听对此的一些意见。

【问题讨论】：

Is it bad practice to have more than Assert in a unit test? 的可能重复项
如果您从验证测试夹具设置与使用多个断言来验证结果的角度来看，我不认为这是重复的。重命名问题以反映这一点可能会有所帮助。
我将重命名以反映建议。 @Carl Manaster：胡须帅哥！

标签： unit-testing testing tdd

【解决方案1】：

正如我所说的here，我认为也许我们的最佳实践应该不是 Arrange-Act-Assert，而是 Arrange-Assume-Act-Assert。在 Acting 之前，我们断言 Action 的预期结果尚未生效。这与您所问的完全不一样；一般来说，我认为验证设置并不重要，因为设置错误在任何情况下都倾向于“大声”地表现出来；但在测试中使用第二个断言是一个很好的理由。

【讨论】：

【解决方案2】：

我认为必须使用 Assert 来验证设置是次优的，因为它会混淆结果（如果只看输出，可能很难弄清楚你在测试什么）。

我知道有时这是必要的，或者您只是想确保一切都按照您想要的方式进行测试。

我的做法是为此目的使用 Debug.Assert（在 C# 中），这样设置验证就不会成为测试输出的一部分。

如果设置未将系统置于预期状态，您也许可以通过抛出异常在其他语言中实现相同的目的。

不同的测试运行器可能会以不同的方式处理此问题，因此您应确保此方法具有预期的效果（测试失败，但只要Debug.Assert 通过或未抛出异常，就不会有额外的报告输出）。

【讨论】：

所有这些都是很好的答案。但是，我选择 Jay's 是因为我喜欢 Debug.Assert 在测试中的读取方式。再次感谢。
不太方便的是 Debug.Assert 仅用于调试。您可以在 CI 中运行您的版本测试，然后测试不同的代码（例如 Debug.Assert 将不再存在）。您可以选择使用 Trace.Assert 但对我来说，用户 Debug.Assert 和 Trace.Assert 在测试中感觉有点奇怪，因为它们似乎是为了根据文档显示消息框：docs.microsoft.com/en-us/dotnet/api/… 有人找到替代方案吗?在测试框架中进行前置条件测试似乎很有用。

【解决方案3】：

我不会为此使用普通的“断言”，而是使用 Assert.Inconclusive (MSTest)¹。测试没有失败，所以您不想让测试运行失败。

1) Assume 我相信在 JUnit 和 NUnit 中。

【讨论】：

链接到Assert.Inconclusive