Assert.That vs Assert.True

更喜欢什么：

Assert.That(obj.Foo, Is.EqualTo(true))

要么

 Assert.True(obj.Foo)

对我来说，两个断言都是等价的，那么哪一个应该是首选的？

在这种特殊情况下，没有区别：您将看到大致相同细节级别的输出（即它告诉您预期评估为true已评估为false ）。同样的

 Assert.IsTrue(obj.Foo);

和

 Assert.That(obj.Foo, Is.True);

您的团队应该选择一种断言方式，并在所有测试中坚持使用。如果你的团队更喜欢Assert.That样式，那么你应该使用Assert.That(obj.Foo, Is.True) 。

Assert.That这称为基于约束的模型。它很灵活，因为该方法采用IConstraint类型的参数。这意味着您可以使用更通用的层次结构或调用结构来构建代码，并传入任何旧的IConstraint 。这意味着您可以构建自己的自定义约束

这是一个设计问题。正如大家所说，无论你还需要提供体面的错误信息反馈。

好吧，你在CI服务器上执行了测试套件，不幸的是，其中一个失败了。您打开日志并查看下一条消息

 BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false

现在你怎么会得到这些测试发生的错误，如果你看到的所有信息都是AutoLoginTests bool中的某个地方预计是真的，但收到了错误？现在您需要转到测试用例的源文件，看看断言失败了什么。你看

 Assert.True(obj.Foo)

令人惊讶的是……只有在1小时前开发此模块时，仍然很难分辨出什么是错的。你仍然需要深入研究测试源和可能的生产源，甚至调试你的代码，这样你最终可以弄清楚，你拼错了函数调用中的变量或使用了错误的谓词来过滤注册用户。因此，您阻止了测试的即时反馈，这非常有价值。

我的观点是，你的断言是多么流利（这也是相关的）并不重要，但是在测试失败的情况下你会暴露什么信息，以及你有多快得到失败的根本原因，即使你工作了很长时间以前有这个function

这有点挑剔，但恕我直言，我认为在这种情况下Assert.That 。这是不必要的冗长，因此可以被视为混淆。换句话说， Assert.True更清晰，更直接，更容易阅读，因此可以理解。

为了得到更多的挑剔我建议使用Assert.IsTrue API而不是Assert.True因为再次恕我直言， IsTrue “读取”更好。