喜欢什么：
Assert.That(obj.Foo, Is.EqualTo(true))
或
Assert.True(obj.Foo)
对我来说，这两个断言是等价的，那么应该首选哪一个？
【问题讨论】：
obj.Foo.Should().BeTrue(); fluentassertions.codeplex.com （你使用什么并不重要，只要它是可读的，并且可以将你试图达到的目标传递给读者）
标签： c# unit-testing nunit
在这种特殊情况下，没有区别：您将看到大致相同详细程度的输出（即，它告诉您预期评估为 true 的内容已评估为 false）。也一样
Assert.IsTrue(obj.Foo);
和
Assert.That(obj.Foo, Is.True);
您的团队应该选择一种断言风格，并在所有测试中坚持使用它。如果您的团队更喜欢Assert.That 样式，那么您应该使用Assert.That(obj.Foo, Is.True)。
【讨论】：
Assert.That 称为基于约束的模型。它很灵活，因为该方法采用IConstraint 类型的参数。这意味着您可以使用更通用的层次结构或调用结构来构建您的代码，并传入任何旧的IConstraint。这意味着您可以构建自己的custom constraints
这是一个设计问题。正如大家所说，无论您做什么，仍然需要提供体面的错误消息反馈。
【讨论】：
好吧，你在 CI 服务器上执行了你的测试套件，不幸的是，其中一个失败了。您打开日志并查看下一条消息
BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false
现在，如果您看到的所有信息是 AutoLoginTests bool 中的某处预期为 true，但收到 false，您究竟会如何得知此测试发生了什么错误？现在您需要转到测试用例的源文件并查看哪些断言失败了。你看
Assert.True(obj.Foo)
太神奇了.. 仍然很难判断出了什么问题，除非您在 1 小时前开发了这个模块。您仍然需要更深入地研究测试源和可能的生产源，甚至调试您的代码，以便您最终弄清楚，您在函数调用中拼错了变量或使用了错误的谓词来过滤注册用户。因此，您阻止了测试的即时反馈，这非常有价值。
我的观点是，你的断言有多流畅（这也是相关的）并不重要，重要的是你在测试失败的情况下暴露了哪些信息，以及你能以多快的速度获得失败的根本原因，即使你工作了很久以前就有这个功能了
【讨论】：
这有点挑剔，但恕我直言，我认为在这种情况下Assert.That 是不必要的冗长，因此可以被视为混淆。换句话说，Assert.True 更简洁、更直接、更易于阅读和理解。
为了更加挑剔，我建议使用Assert.IsTrue API 而不是Assert.True，因为恕我直言，IsTrue“阅读”更好。
【讨论】：