単体テストの制約とNUnit構文ヘルパーについて

Question

私と同僚は新しいプロジェクトを開始し、TDDを最大限に活用しようとしています。私たちはまだ単体テストに関するすべての概念を把握しており、これまでのところ主に他の例に基づいています。

最近、同僚がNUnitシンタックスヘルパーのポイントに疑問を持ち、彼らの利点を説明するのに苦労しています（私の腸は彼らが良いと言う以外は自分でそれを本当に理解していないからです！）アサーションの例を次に示します。

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

これは完全に理にかなっていますが、 product.IsValid（）の値は false であると期待しています。一方、同僚は次のように書くことを好むでしょう。

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

彼は、これはより理にかなっており、読みやすくなると言っています。

これまでのところ私たちが同意できる唯一のことは、前者からのテストが失敗した場合により有用な出力が得られる可能性が高いということですが、より良い説明が必要だと思います。構文ヘルパーに関する情報を調べました（ http://nunit.com/blogs/？ p = 44 ）そしてそれらは理にかなっていますが、私はそれらが正しいと感じる以外の制約の概念を完全には理解していません。

制約の概念を使用する理由と、上記の単体テストの例が改善される理由を誰かが説明できますか？

ありがとう。

Answer 1

私は主に声明の純粋な英語の読みと関係があると思います。

最初の読み取り

  

製品が有効であることを確認するのは誤りです

2番目の読み取り

  

製品ではないことをアサートする

個人的には、最初のほうが処理しやすいと思います。私はそれが本当に好み次第だと思うそこにある拡張メソッドのいくつかは興味深いですが、次のようなアサーションを実行できます：

product.IsValid().IsFalse();

Answer 2

あなたのバージョンは同僚よりも優れていることがわかります。ただし、少なくとも次のことに慣れています。

Assert.IsFalse(product.IsValid());

Assert.That 構文が上記よりも客観的な利点があることを納得させることができたら、私は非常に興味があります:) ＆quot;どのようなアサーションを作成していますか？今、私たちはそれについて何を主張していますか？」スタイル。

Answer 3

それはすべて砂糖です。内部的には制約に変換されます。

実用的な単体テスト、37ページから：

＆quot; NUnit 2.4は、少し手順が少なく、オブジェクト指向の基礎となる実装を可能にする新しいスタイルのアサーションを導入しました。 ... 例えば：

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

変換先：

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

制約を使用すると、制約から継承して、一貫した構文を維持しながら独自のカスタム制約を作成することもできます。

Answer 4

私はAssert.Thatが好きではありません。具体的には、最も一般的なシナリオ（2つのオブジェクトの同等性を比較）が「古典的な」Assert.AreEqual（）構文よりも明らかに悪いという事実です。

一方、私はMSpec NUnit拡張機能が大好きです。それらをチェックアウトすることをお勧めします（またはSpecUnit拡張機能、NBehave拡張機能、またはN Behave Spec * Unit拡張機能を見てください。すべて同じだと思います）。