次の方法を検討してください
public void Foo(string str)
{
if (str == null)
throw new ArgumentNullException("str");
if (str.Length != 5)
throw new MyException();
}
次のようにネガティブ テストを書きたいとします。
public void TestFoo()
{
try
{
Foo(null); //this could be an remote call (e.g. WCF)
Assert.Fail("Expected ArgumentNullException");
}
catch (ArgumentNullException) {} //should this be "Exception" instead?
try
{
Foo("four"); //this could be an remote call (e.g. WCF)
Assert.Fail("Expected MyException");
}
catch (MyException) {} //should this be "Exception" instead?
}
上記のように特定の例外をキャッチすることは実装の詳細であるように思われます。これにより、テストが脆弱になり、(インターフェイスではなく) 実装と結合しすぎる可能性があります。明らかにMyException
、いつか変更ArgumentNullException
される可能性がありますが、たとえば、他の例外にラップされる可能性もあります (たとえば、将来の WCF の動作によって)。通常、テストは「4」が失敗する必要があることを認識しており、それが気にするのは失敗だけです。
UserNameTakenException
これに対する例外 (しゃれは意図されていません) は、ユーザーフレンドリーなメッセージ (たとえば、既に使用されているユーザー名にマップされている、別の名前を試してください)など、ユーザーに渡されるものに例外が変換される場合です。. このような場合、正しいエラーが伝えられるようにする必要があります。それでも、可能性のあるユーザー エラーごとに異なる種類の例外を意味するため、少し問題がありますが、それほど悪くはありません (通常、それらの多くはありません)。
私の考え方は理にかなっていますか?Exception
ユーザー向けの例外を含まないテストケースでジェネリックを実際にキャッチする必要がありますか?