2

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

私の同僚は最近、NUnit 構文ヘルパーの要点に疑問を投げかけました。アサーションの例を次に示します。

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

私にはこれは完全に理にかなっていproduct.IsValid()ますfalse。一方、私の同僚は、単純に次のように書くことを好みます。

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

彼は彼に、これはより理にかなっており、より簡単に読むことができると言います.

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

制約の概念を使用する理由と、上記の単体テストの例を改善する理由を誰かが説明できるのだろうか?

ありがとう。

4

4 に答える 4

4

それは主に、声明の純粋な英語の読み方に関係していると思います。

最初の読み取り

製品が有効であると主張するのは誤りです

2番目の読み取り

製品が有効ではないことを主張する

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

product.IsValid().IsFalse();
于 2009-03-04T10:48:54.733 に答える
3

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

Assert.IsFalse(product.IsValid());

構文が上記よりも客観的な利点を持っていることを私に納得させることができればAssert.That、私は非常に興味があります:)それは単に習慣の力かもしれませんが、私は非常に簡単に「私たちはどのような主張をしているのですか?私たちはそれについて主張していますか？」スタイル。

于 2009-03-04T11:14:03.330 に答える
1

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

Pragmatic Unit Testing、pg 37 から:

「NUnit 2.4 では、手続き的ではなく、よりオブジェクト指向の基本的な実装を可能にする新しいスタイルのアサーションが導入されました。たとえば、次のようになります。

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

に変換:

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

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

于 2009-03-04T19:03:28.960 に答える
0

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

一方、私は MSpec NUnit 拡張機能が大好きです。それらを確認することをお勧めします (または、SpecUnit 拡張機能、NBehave 拡張機能、または N Behave Spec*Unit 拡張機能を調べてください。それらはすべて同じだと思います)。

于 2009-05-27T05:13:42.260 に答える