了解单元测试约束和 NUnit 语法帮助器
我和一位同事正在启动一个新项目并尝试充分利用 TDD。 我们仍在弄清楚有关单元测试的所有概念，并且到目前为止它们主要基于其他示例。
我的同事最近对 NUnit 语法助手的意义提出了质疑，我正在努力解释它们的好处（因为我自己并不真正理解它，除了我的直觉说它们很好！）。 这是一个示例断言：
Assert.That(product.IsValid(), Is.False);
对我来说，这是完全有道理的，我们是说我们期望 product.IsValid() 的值为 false。 另一方面，我的同事希望我们简单地写：
Assert.That(!product.IsValid());
他对他说这更有意义，他可以更轻松地阅读。
到目前为止，我们唯一可以同意的是，当前者的测试失败时，您可能会得到更有用的输出，但我认为必须有更好的解释。 我查找了有关语法助手的一些信息（http://nunit.com/blogs/? p=44），它们是有道理的，但除了它们“感觉”正确之外，我并不完全理解约束的概念。
我想知道是否有人可以解释为什么我们使用约束的概念，以及为什么他们改进上面的单元测试示例？
谢谢。
Me and a colleague are starting a new project and attempting to take full advantage of TDD. We're still figuring out all the concepts around unit testing and are thus far basing them primarily on other examples.
My colleague recently brought into question the point of the NUnit syntax helpers and I'm struggling to explain their benefit (since I don't really understand it myself other than my gut says they're good!). Here is an example assertion:
Assert.That(product.IsValid(), Is.False);
To me this makes complete sense, we're saying we expect the value of product.IsValid() to be false. My colleague on the other hand would prefer us to simply write:
Assert.That(!product.IsValid());
He says to him this makes more sense and he can read it easier.
So far the only thing we can agree on is that you are likely to get more helpful output when the test is failing from the former, but I think there must be a better explanation. I've looked up some information on the syntax helpers (http://nunit.com/blogs/?p=44) and they make sense, but I don't fully understand the concept of constraints other than they 'feel' right.
I wonder if someone could explain why we use the concept of constraints, and why they improve the unit test examples above?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我认为这主要与该声明的纯英文阅读有关。
第一个读到
第二个读取
我个人认为第一个更容易处理。 我认为这完全取决于偏好。 一些扩展方法很有趣，可以让你像这样进行断言：
I think it's mostly to do with the pure English reading of the statement.
The first reads
The second reads
I personally find the first easier to process. I think it's all down to preference really. Some of the extension methods out there are interesting though that let you do you assertions like this:
我可以看到你的版本比你的同事更好。 但是，我仍然至少会感到满意：
如果您能让我相信
Assert.That语法比上述语法具有客观优势，我会非常感兴趣:) 它很可能只是习惯的力量，但我可以很容易地读到“我们在做出什么样的断言？现在我们在断言什么？” 风格。I can see your version being better than your colleagues. However, I'd still be at least as comfortable with:
If you can convince me that the
Assert.Thatsyntax has an objective benefit over the above, I'd be very interested :) It may well just force of habit, but I can very easily read the "What kind of assertion are we making? Now what are we asserting it about?" style.都是糖。 在内部它们被转换为约束。
来自实用单元测试，第 37 页：
“NUnit 2.4 引入了一种新的断言风格，这种断言的程序性稍差一些，并且允许更加面向对象的底层实现。
...
例如：
转换为：
使用约束还允许您继承 Constraint 并创建自己的自定义约束，同时保持一致的语法。
It's all sugar. Internally they're converted to constraints.
From Pragmatic Unit Testing, pg 37:
"NUnit 2.4 introduced a new style of assertions that are a little less procedural and allow for a more object oriented underlying implementation.
...
For instance:
Converts to:
Using constraints also allows you to inherit from Constraint and create your own custom constraint(s) while keeping a consistent syntax.
我不喜欢 Assert.That，特别是它最常见的场景（比较两个对象的相等性）明显比“经典”Assert.AreEqual() 语法更糟糕。
另一方面，我非常喜欢 MSpec NUnit 扩展。 我建议您检查一下它们（或者查看 SpecUnit 扩展、NBehave 扩展或 NBehaveSpec*Unit 扩展，我认为它们都是相同的）。
I don't like Assert.That, specifically the fact that its most common scenario (comparing two objects' equality) is measurably worse than the 'classic' Assert.AreEqual() syntax.
On the other hand, I super love the MSpec NUnit extensions. I recommend you check them out (or look at the SpecUnit extensions, or NBehave extensions, or NBehaveSpec*Unit extensions, I think they're all the same).