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

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

Answer 3

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

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

Answer 4

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

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

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

Assert.True(obj.Foo)

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

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