2010-12-21 13 views
2

NUnitテストが失敗するように指定する方法はありますか?つまり、失敗をパスとして報告し、失敗を失敗として報告する必要がありますか?これは、独自のNUnit拡張をテストするときに便利です。ここで私が行うことができるようにしたいと思い、何かの例です:NUnitテストが失敗するように指定する方法を教えてください。

[Test] 
[ExpectFail] 
public void TypeOf_fail() { 
    string str = "abc"; 
    str.Should().Be.TypeOf<int>(); 
} 

[ExpectFail]私が何をしたいのか説明するための架空の属性ですが、メソッド内のコードが正常に動作しますので、これはコンパイルされません。 。この問題は、NUnit拡張機能をテストすることに特有のものです。通常は、失敗することなくテストをパスするように簡単に書くことができます。この場合、テストしているNUnit拡張を使って失敗したテストを書くことが可能であることを証明する必要があります。
彼らはいくつかの状態
を設定し、彼らはテスト対象のメソッドが

(参照を完了した後に一つのことが正しいことを主張するテスト
下の方法を実行しますように

+1

私はそれを調べたことはありませんでしたが、コアNUnitコードはテストが失敗することを証明するためにどのように自己テストしますか? –

答えて

1

どうAssert.Throwsについて<XXXException>(x.DoSomething());

ここの良いところは、テストが(つまり、例外がスローされた)合格した場合、戻り値は実際の例外そのものであり、そしてあなたがそれに質問し、それに基づいて、さらに断言できるということです。..考える

この場合、あなたはAssert呼び出しを行うことによって機能することを前提としているNUnit拡張機能をテストしたいと思っています.Assert.Throws <AssertionException>(...)を実行し、上記を行います。

私は順番にテストが必要なかもしれない同様のテスト用配管コードを書くことを考えていますので、このエリアで何か他のものを見つけたらお知らせします。

2

ユニットテストを設計する必要があります。 Roy Osheroveによるユニットテスティングの技術)

悪いことに失敗するように設計されたテストはなぜですか?彼らは予期しない方法で失敗する可能性があり、失敗したためにパスとしてマークされます。あなたの例では、Should()がテスト中のメソッドであると仮定します(この点はそうではなくても残ります)。上記のテストを書き、「失敗すると予想されます」とマークします。それは失敗する。すべて順調。数か月後にShould()に戻り、リファクタリングが必要であることを認識して実装を変更します。

ここでは、誤ってバグを導入したため、Should()は例外をスローします。しかし、あなたのテスト(ロジックではなく例外が原因で失敗する)は、失敗したとマークされ、それが実行されます。

このテストは、予期せぬ別の方法で失敗した場合に通知されるように、失敗しないように設計されている必要があります。だからあなたの例では、反対の論理でテストを書く必要があります。

[Test] 
public void TypeOf_ShouldBeString() { 
    string str = "abc"; 
    str.Should().Be.TypeOf<string>(); 
} 

か:

[Test] 
public void TypeOf_ShouldNotBeInt() { 
    string str = "abc"; 
    str.Should().Not.Be.TypeOf<int>(); 
} 

(あなたが使用している構文のわからないので、.NOTはおそらく正しい構文に置き換えが必要になりますが、しかしその感情は保持している)。

Edit2:しようとしているのは、Should()メソッドが失敗した(Assertメソッドが失敗した)ことを確実にしている場合、AssertのNUnit AssertionExceptionをキャッチすることです。静的メソッドはスローします。これを試してみてください:

[Test] 
[ExpectedException(typeof(AssertionException))] 
public void ShouldBeTypeOf_WithInt_Fails() { 
    string str = "abc"; 
    str.Should().Be.TypeOf<int>(); 
}  
+0

投稿したテストのいずれも、失敗したテストを生成する方法で拡張機能を使用することが可能であることを証明していないため、その解決策が嫌いです。 –

+0

これらの2つのテストの組み合わせでも、NUnit拡張機能を使用して失敗したテストを作成することはできないことがわかります。 –

+0

@INTPnerd:私の答えを編集して、私のポイントを少し説明しました。 –

0

あなたは、コードのブロックを渡すために、テストのために例外をスローすることが期待されていることを意味している場合、ここでのコードは次のとおりです。もちろん

[Test] 
[ExpectedException(typeOf(Exception))] 
public void TypeOf_fail() { 
    string str = "abc"; 
    str.Should().Be.TypeOf<int>(); 
} 

、可能な限り最も特定の例外と例外を置き換えます。

0

私はこれは古い記事ですが、ここではNUnitのを使用して、私を助けているものである知っている:

[TestCase("SomeValidValue")] 
[TestCase("{3X5XFX9X-7XCX-4XCX-8X3X-3XAXEX9X0XBX}", ExpectedException = typeof(AssertionException))] 
public void GetSpecificConfiguration(string key) 
{ 
    Assert.IsNotNull(Config.Instance.GetRecord(key)); 
} 

このアプローチは、2つの期待、1が続く、と1回の失敗で、私は同じテストを持つことができます。

関連する問題