Question

我和一位同事正在开始一个新项目并试图充分利用TDD。我们仍在研究有关单元测试的所有概念，因此它们主要基于其他示例。

我的同事最近对NUnit语法助手的问题提出了质疑，我正在努力解释他们的好处（因为我自己并不是真的了解它，除了我的直觉说他们很好！）。这是一个示例断言：

Assert.That(product.IsValid(), Is.False);

对我来说这完全合情合理，我们说我们希望product.IsValid()的价值为false。另一方面，我的同事宁愿我们简单地写一下：

Assert.That(!product.IsValid());

他对他说这更有意义，他可以更容易阅读。

到目前为止，我们唯一能够达成共识的是，当测试失败时，你可能会获得更多有用的输出，但我认为必须有更好的解释。我已经查找了有关语法助手（http://nunit.com/blogs/?p=44）的一些信息并且它们有意义，但我并不完全理解约束的概念，除了它们“感觉”正确。

我想知道是否有人可以解释为什么我们使用约束的概念，以及为什么它们会改进上面的单元测试示例？

感谢。

Answer 1

我认为这主要与纯正的英语阅读声明有关。

第一次读取

断言产品有效是

第二次读取

断言产品无效

我个人觉得第一个更容易处理。我认为这完全取决于偏好。有些扩展方法很有意思，但是你可以使用这样的断言：

product.IsValid().IsFalse();

Answer 2

我可以看到你的版本比你的同事更好。但是，我仍然至少对以下内容感到满意：

Assert.IsFalse(product.IsValid());

如果你能说服我Assert.That语法比上面有客观的好处，我会非常感兴趣:)这可能只是习惯的力量，但我可以很容易地读到“什么样的我们在做什么断言？现在我们断言它是什么？“风格。

Answer 3

这都是糖。在内部，他们被转换为约束。

从语用单位测试，第37页：

“NUnit 2.4引入了一种新的断言方式，它的程序性稍差，并允许更面向对象的底层实现。 ... 例如：

Assert.That(actual, Is.EqualTo(expected));

转换为：

Assert.That(actual, new EqualConstraint(expected));"

使用约束还允许您从Constraint继承并创建自己的自定义约束，同时保持一致的语法。

Answer 4

我不喜欢Assert。特别是它最常见的场景（比较两个对象的相等）比'经典'Assert.AreEqual（）语法更糟糕。

另一方面，我非常喜欢MSpec NUnit扩展。我建议你检查它们（或查看SpecUnit扩展，或NBehave扩展，或N Behave 规范*单元扩展，我认为它们都是一样的。）