Assert.That vs Assert.True

Question

首选内容：

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

或

Assert.True(obj.Foo)

对我来说，这两个断言是等价的，那么哪一个应该更好呢？

Answer 1

在本例中，没有区别:您将看到大致相同细节级别的输出(即，它告诉您预期计算为true的内容已计算为false)。情况也是如此。

Assert.IsTrue(obj.Foo);

和

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

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

Answer 2

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

这是一个设计问题。正如每个人都在说的那样，无论你需要什么，仍然需要提供像样的错误消息反馈。

Answer 3

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

BusinessLogicTests.LoginTests.UserAutoLoginTests失败:应为true，但实际为false

那么，如果您看到的所有信息都是AutoLoginTests bool中的某个地方被认为是真的，但收到的却是假的，那么您如何才能得出这个测试发生了什么错误呢？现在，您需要转到测试用例的源文件，查看哪些断言失败。你看

Assert.True(obj.Foo)

令人惊讶的是..。如果你在1小时前就开发了这个模块，那就很难判断出哪里出了问题。您仍然需要更深入地研究测试源代码，甚至可能是生产源代码，甚至调试您的代码，这样您才能最终找出您在函数调用中拼写错误的变量，或者使用错误的谓词来过滤注册用户。因此，您阻止了来自测试的即时反馈，这是非常有价值的。

我的观点是，你的断言有多流畅(这也是相关的)并不重要，重要的是你在测试失败的情况下暴露了什么信息，以及你多快能找到失败的根本原因，即使你很久以前就用过这个函数