テストメソッドでtry catchを使用する必要がありますか？

ユニットテストを行っています。

1つの機能をテストしようとしています。

テストコンポーネントから呼び出します。しかし、リモート関数が例外を処理できない場合、テスターコンポーネントも例外を取得します。

テスターコンポーネントで例外が発生することを心配する必要がありますか？

ありがとう。

編集：

PS：

エラーを投げることは良いことですが、最後の選択肢になるまでエンドユーザーにではなく、他の機能に対してのみです！

OMG私はプログラミングの見積もりを書きました!!

短い答え：いいえ。

単体テストで例外をキャッチしないでください。エラーと例外が発生する状況を見つけるための単体テストです。

単体テストフレームワークは、例外を正常に処理する必要があります。ほとんどの（すべてではないにしても）xUnitフレームワークには、テスト対象のシステムで特定の例外条件を引き起こしたいときに使用する特定の例外を予期する構造があり、予期される例外が発生した場合はテストに合格し、そうでない場合は失敗します。

（mcottleの答えとは対照的に）長い答え：いいえ...ほとんどの場合

テストで特定の例外が発生することを期待していると言うと、そのテストのどの行でもその特定の例外が発生することがわかります。

これは、テスト対象のメソッドが例外をスローすることを知っているのとまったく同じことではありません。

テストに（フレームワークのバージョンではなく、テスト内で）オブジェクトまたはコンテキストのセットアップが含まれる場合、SetUp実際にテストする1行を、おそらくヘルパーを使用して、try / catchでラップする方がよい場合があります。

例えば、

public static class AssertHelper {
    public delegate void Thunk();

    public static void DoesNotThrow<T>(Thunk thunk, string message = "")
        where T: Exception {
        try {
            thunk.Invoke();
        } catch(T) {
            Assert.Fail(message);
        }
    }
}

その後

[TestMethod]
public void assertHelperInAction() {
    // Random setup stuff here that's too annoying to put in my SetUp
    // method.
    AssertHelper.DoesNotThrow<IllegalArgumentException>(() =>
        {/* My random method under test */})
}

このテストが失敗した場合、テスト中のメソッドが例外をスローしたことを知っており、ランダムなセットアップのものではありません。

（ランダムなセットアップなどを避けてください。テストでセットアップコードを使用する方が簡単な場合があります。）

一般に、例外を除外するだけで、テストフレームワークは必要なすべての情報を含む優れたレポートを提供します。

しかし、TDD方法論では、次の手順に従うことが期待されています。

1. テストを書く
2. 失敗するのを見て、エラーを理解できるようにします
3. コードを修正する
4. コードとテストをリファクタリングする

例外を出したときに、エラーが明確であれば問題ありません。しかし、例外はあいまいな場合もあれば、誤解を招く場合もあります。どうすればそれをあなたのコードに入れることができますか（あなたが忘れてしまった後、または問題を解明するのに大きな時間を失うチームメンバーのために）？したがって、私のポリシーは次のとおりです。「障害を明確にする必要がある場合は、例外をキャッチする必要があります」。