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

我和一位同事正在开始一个新项目并尝试充分利用TDD。我们仍然在搞清楚单元测试的所有概念，并且主要基于其他例子。了解单元测试约束和NUnit语法助手

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

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

对我来说，这使得完整意义上，我们说，我们期待product.IsValid()值是false。我在另一方面同事宁愿我们简单地写：

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

他对他说，这使得更多的意义，他可以阅读更加容易。

到目前为止，我们唯一可以同意的是，当测试失败时，您可能会获得更有用的输出，但我认为必须有更好的解释。我查了一下关于语法帮助器的一些信息（http://nunit.com/blogs/?p=44），它们是有道理的，但我不完全理解约束的概念，而不是他们'感觉'正确。

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

谢谢。

来源

2009-03-04 roryf

在这里真正复杂的约束使用的示例http://geekswithblogs.net/mrsteve/archive/2012/02/13/writing-readable-unit-tests-clean-code-handbook-agile-software-craftsmanship.aspx – 2013-07-31 16:52:30

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

第一读取

断言，产品有效期是假

第二读取

断言，而不是产品是有效的

我个人觉得第一个更容易处理。我认为这完全取决于偏好。

product.IsValid().IsFalse();

来源

2009-03-04 10:48:54

这几乎是我对语法助手的看法，我更加关注底层约束的目的。还是他们出于同样的原因，语法助手只是一个改进？ – roryf 2009-03-04 11:09:36

我很喜欢语法助手，因为他们使断言听起来像一个句子。然而，我对正常的语法很满意，因此找不到任何理由强迫其他人使用语法助手。 – mezoid 2009-03-04 11:24:40

我可以看到你的版本比你的同事更好：虽然这让你做你喜欢这个断言一些扩展方法在那里很有趣。不过，我还是会至少与舒适：

Assert.IsFalse(product.IsValid());

如果你能说服我，Assert.That语法有超过上述的客观利益，我会很感兴趣:)很可能只是力的习惯，但我可以很容易地读到“我们在做什么样的断言？现在我们断言什么？”样式。

来源

2009-03-04 11:14:03

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

的语用单元测试，第37页：

“NUnit的2。4引入了一种新型的断言，这种断言稍微程序化，并允许更多的面向对象的底层实现。 ... 例如：

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

转换为：

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

使用约束，您还可以从约束继承和创建自己的定制约束（S），同时保持了一致的语法。

来源

2009-03-04 19:03:28

我不喜欢Assert.That，尤其是它最常见的情况（比较两个对象的相等）的事实明显比'classic'Assert.AreEqual（）语法差。

另一方面，我非常喜欢MSpec NUnit扩展。我建议你检查一下（或者查看SpecUnit扩展，或者NBehave扩展，或者N Behavi Spec * Unit扩展，我认为它们都是一样的）。

来源

2009-05-27 05:13:42

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

回答

相关问题