C# Assert.That 与 Assert.True
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/16086870/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Assert.That vs Assert.True
提问by Razer
What to prefer:
更喜欢什么：
Assert.That(obj.Foo, Is.EqualTo(true))
or
或者
Assert.True(obj.Foo)
For me, both asserts are equivalent, so which one should be prefered?
对我来说，这两个断言是等价的，那么应该首选哪一个呢？
采纳答案by dasblinkenlight
In this particular case, there is no difference: you will see the output of roughly the same level of detail (i.e. it tells you that something that was expected to evaluate to truehas evaluated to false). Same goes for
在这种特殊情况下，没有区别：您将看到大致相同详细程度的输出（即它告诉您预期评估为的内容true已评估为false）。同样适用
Assert.IsTrue(obj.Foo);
and
和
Assert.That(obj.Foo, Is.True);
Your team should pick one style of assertions, and stick with it throughout all your tests. If your team prefers the Assert.Thatstyle, then you should use Assert.That(obj.Foo, Is.True).
您的团队应该选择一种断言风格，并在所有测试中坚持使用它。如果您的团队更喜欢这种Assert.That风格，那么您应该使用Assert.That(obj.Foo, Is.True).
回答by Paul Sasik
This is a bit nit-picky but IMHO I think that in this case Assert.Thatis unnecessarily verbose and can therefore be regarded as obfuscation. In other words, Assert.Trueis a little cleaner, more straightforward and easier to read and therefore comprehend.
这有点挑剔，但恕我直言，我认为在这种情况下Assert.That不必要地冗长，因此可以被视为混淆。换句话说，Assert.True它更简洁、更直接、更易于阅读和理解。
To get a little more nit-picky I would suggest using the Assert.IsTrueAPI instead of Assert.Truesince, again IMHO, IsTrue"reads" better.
为了更加挑剔，我建议使用Assert.IsTrueAPI 而不是Assert.True因为，恕我直言，IsTrue“阅读”更好。
回答by Ilya Ivanov
So ok, you executed your test suite on CI server and unfortunately, one of them failed. You open the logs and see next message
好吧，你在 CI 服务器上执行了你的测试套件，不幸的是，其中一个失败了。您打开日志并查看下一条消息
BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false
BusinessLogicTests.LoginTests.UserAutoLoginTests failed: expected true but was false
Now how on earth would you get what happened wrong with this tests, if all the information you see, is that somewhere in AutoLoginTests bool was expected true, but received false? Now you need to go to the source file of your tests cases and see, what assertion failed. You see
现在，如果您看到的所有信息是 AutoLoginTests bool 中的某个地方预期为真，但收到的信息为假，那么您到底怎么会知道这个测试发生了什么问题？现在您需要转到测试用例的源文件并查看哪些断言失败。你看
Assert.True(obj.Foo)
Amazingly.. it's still hard to tell what's wrong, only if you developed this module 1 hour ago. You still need to go deeper into tests sources and probably production sources or even debug your code, so that you can at last figure out, that you misspelled a variable inside function call or used wrong predicate to filter registered users. Thus you blocked immediate feedback from tests, which is very valuable.
令人惊讶的是.. 仍然很难判断出了什么问题，只有您在 1 小时前开发了这个模块。您仍然需要更深入地了解测试源和可能的生产源，甚至调试您的代码，以便您最终确定是您在函数调用中拼错了变量还是使用了错误的谓词来过滤注册用户。因此，您阻止了来自测试的即时反馈，这是非常有价值的。
My point is that it's dosn't matter how fluent your assertions are (which are also relevant), but what information you expose in case of failing tests and how fast can you get the underlying reason of failure, even if you worked a long time ago with this functionaluty
我的观点是，你的断言有多流畅并不重要（这也是相关的），但是在测试失败的情况下你公开什么信息以及你能多快地获得失败的根本原因并不重要，即使你工作了很长时间以前有这个功能
回答by radarbob
Assert.Thatis called the constraint-based model. It's flexible because the method takes a parameter of IConstrainttype. This means you can structure your code with a more generic hierarchy or calling structure, passing in any old IConstraint. It means you can build your own custom constraints
Assert.That称为基于约束的模型。它很灵活，因为该方法需要一个IConstraint类型的参数。这意味着您可以使用更通用的层次结构或调用结构来构建代码，将任何旧的IConstraint. 这意味着您可以构建自己的自定义约束
That's a design issue. As everyone is saying, no matter what you still need to provide decent error message feedback.
那是设计问题。正如大家所说，无论您做什么，您仍然需要提供体面的错误消息反馈。
