Assert.That与Assert.True对我来说，这两种断言是等价的，那么应该首选哪一种呢？在这种特殊情况下，没有区别：您将看到大致相同详细程度的输出（即它告诉您预期的评估为真已评估为假）。同样Assert.IsTrue(obj.Foo);和Assert.That(obj.Foo,Is.True);您的团队应该选择一种断言风格并在所有测试中坚持使用。如果您的团队更喜欢Assert.That风格，那么您应该使用Assert.That(obj.Foo,Is.True)。断言。这称为基于约束的模型。它很灵活，因为该方法采用IConstraint类型的参数。这意味着您可以使用更通用的层次结构或调用结构来构建代码，并传入任何旧的IConstraint。这意味着您可以构建自己的自定义约束这是一个设计问题。正如大家所说，无论你还需要提供体面的错误信息反馈。好吧，你在CI服务器上执行了测试套件，不幸的是，其中一个失败了。您打开日志并看到下一条消息BusinessLogicTests.LoginTests.UserAutoLoginTestsfailed:expectedtruebutwasfalse现在，如果您看到的只是AutoLoginTests中的某处，您如何获得这些测试发生的错误boolExpectedtobetrue，但是得到了一个错误？现在您需要转到测试用例的源文件，看看是什么断言失败了。你看Assert.True(obj.Foo)厉害了。。。1小时前才开发这个模块的时候，还分不清哪里出了问题。您仍然需要深入研究测试源和可能的生产源，甚至调试您的代码，以便您最终可以弄清楚，您在函数调用中拼错了变量或使用了错误的谓词来过滤注册用户。所以你阻止了测试的即时反馈，这是非常有价值的。我的观点是，你的断言有多流畅（这也是相关的）并不重要，重要的是你在测试失败的情况下公开了什么信息，以及你多快找到失败的根本原因，即使你很多工作很久以前就有这个功能。有点挑剔，但恕我直言，我认为Assert.就是这样。这是不必要的冗长，因此可以被视为混淆。换句话说，Assert.True更清晰、更直接、更易于阅读，因此更易于理解。为了更加挑剔，我建议使用Assert.IsTrueAPI而不是Assert.True，因为再次恕我直言，IsTrue“读起来”更好。以上就是C#学习教程：Assert.ThatvsAssert.True分享的全部内容。如果对你有用，需要进一步了解C#学习教程，希望大家多多关注。本文收集自网络，不代表立场。如涉及侵权，请点击右侧联系管理员删除。如需转载请注明出处：
