unit-testing - 了解单元测试约束和 NUnit 语法助手

Question

我和一位同事正在开始一个新项目并尝试充分利用 TDD。我们仍在弄清楚单元测试的所有概念，并且到目前为止主要基于其他示例。

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

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

对我来说，这完全有道理，我们说我们期望的product.IsValid()值为false。另一方面，我的同事希望我们简单地写：

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

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

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

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

谢谢。

score 4 · Accepted Answer

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

第一个读

断言产品有效是假的

第二个读

断言非产品是有效的

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

product.IsValid().IsFalse();

score 3 · Accepted Answer

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

Assert.IsFalse(product.IsValid());

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

score 1 · Accepted Answer

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

来自实用单元测试，第 37 页：

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

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

转换为：

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

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

score 0 · Accepted Answer

我不喜欢 Assert.That，特别是它最常见的场景（比较两个对象的相等性）明显比“经典” Assert.AreEqual() 语法差。

另一方面，我超级喜欢 MSpec NUnit 扩展。我建议您检查它们（或查看 SpecUnit 扩展，或 NBehave 扩展，或 N Behave Spec*Unit 扩展，我认为它们都是相同的）。

4 回答 4