瞭解單元測試約束和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語法助手

回答

相關問題