断言与真断言

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 。 这意味着您可以建立自己的自定义约束

那是一个设计问题。 就像大家都说的那样，不管您仍然需要提供什么体面的错误消息反馈。

Answer 3

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

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

现在，如果您看到的所有信息都是，AutoLoginTests bool中的某个地方应该是正确的，但收到的是错误的，那么您将如何弄清楚该测试出了什么问题？ 现在，您需要转到测试用例的源文件，看看什么断言失败了。 你看

Assert.True(obj.Foo)

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

我的观点是，断言的流畅程度（也很相关）都无关紧要，但是即使测试时间很长，在测试失败的情况下您可以暴露哪些信息，以及获得故障的根本原因的速度有多快以前有这个功能

Answer 4

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

为了更加挑剔，我建议使用Assert.IsTrue API而不是Assert.True因为恕我直言， IsTrue更好地“读取”。