私は TDD を行うときに Assert.Fail をよく使用します。通常は一度に 1 つのテストに取り組んでいますが、後で実装したいもののアイデアが浮かんだときは、テスト メソッドの名前で実装したいものを ToDo リストのように示す空のテストをすぐに作成します。忘れないように、本文に Assert.Fail() を入れます。
xUnit.Net を試してみたところ、Assert.Fail が実装されていないことがわかりました。もちろん、Assert.IsTrue(false) を使うこともできますが、これでは私の意図が伝わりません。Assert.Fail が意図的に実装されていないという印象を受けました。これは悪い習慣とみなされますか? そうであれば、その理由は何ですか?
@Martin Meredith それは私がやっていることではありません。まずテストを書いて、それからそれが機能するようにコードを実装します。通常、一度に複数のテストを考えます。または、他の作業をしているときに、書くテストについて考えます。そのときに、覚えておくために空の失敗するテストを書きます。テストを書くときには、きちんとテストファーストで作業します。
@Jimmeh それはいいアイデアですね。無視されたテストは失敗しませんが、別のリストに表示されます。試してみなければなりません。
@Matt Howells 素晴らしいアイデアです。この場合、NotImplementedException は assert.Fail() よりも意図を伝えるのに適しています。
@Mitch Wheat まさに私が探していたものです。別の方法で悪用されるのを防ぐために省略されたようです。
ベストアンサー1
このシナリオでは、Assert.Failを呼び出すのではなく、次の操作を実行します（C# / NUnitの場合）
[Test]
public void MyClassDoesSomething()
{
throw new NotImplementedException();
}
Assert.Fail よりも明示的です。
Assert.Fail() よりも明示的なアサーションを使用する方が望ましいという一般的な合意があるようです。しかし、ほとんどのフレームワークは、よりよい代替手段を提供していないため、これを組み込む必要があります。たとえば、NUnit (およびその他) は、コードが特定のクラスの例外をスローすることをテストするための ExpectedExceptionAttribute を提供します。ただし、例外のプロパティが特定の値に設定されていることをテストするには、これを使用できません。代わりに、Assert.Fail を使用する必要があります。
[Test]
public void ThrowsExceptionCorrectly()
{
const string BAD_INPUT = "bad input";
try
{
new MyClass().DoSomething(BAD_INPUT);
Assert.Fail("No exception was thrown");
}
catch (MyCustomException ex)
{
Assert.AreEqual(BAD_INPUT, ex.InputString);
}
}
xUnit.Net メソッドアサート.スロー(またはバリエーションの ThrowsAsync、ThrowsAny) を使用すると、Assert.Fail メソッドを必要とせずに、はるかにすっきりします。Assert.Fail() メソッドを含めないことで、xUnit.Net は開発者がより明示的な代替手段を見つけて使用し、必要に応じて新しいアサーションの作成をサポートすることを推奨します。