アクションのテストが非常に複雑な場合（特に入力のモックと環境のセットアップ）に状況が発生しましたか？
これは、コントローラーに多くの依存関係があり、それらがそれらに緊密に接続されている場合に発生します。それが既存のコードであり、コードに変更を加えることでより多くの問題が発生しない限り、インターフェイスまたは抽象クラスを介して依存関係を緩く結合する必要があります。これにより、ユニットのテストが非常に簡単になります。Session、Cacheなどのオブジェクトのラッパーも使用する必要があります。
@Dismissileが示唆しているように、最初にコントローラーをリファクタリングする必要があり、次に単体テストが簡単になります。
コントローラにビジネスロジックを組み込むための適切なアプローチを見つけましたか。または、サービス呼び出しを中継するだけのサービスとコントローラーコードを使用する方が良いと思いましたか？
コントローラーは、ビジネスロジックを配置する場所ではありません。すべてのビジネスロジックはModelクラスに含まれている必要があります。コントローラの全責任は、モデルと通信し、ビュー、json、またはその他のものをクライアントに返すことです。コントローラに複雑なビジネスロジックがある場合は、それらをモデルクラスに移動する必要があります。
単純に、「ダンプビュー..シンコントローラ..ファットモデル」について考える必要があります。
私の意見では、コントローラーのテストは、単体テストよりも統合テストと同等です。あなたはこのことについてどう思いますか？
統合テストは、単体テストとはまったく異なります。統合テストでは、アプリケーションをセットアップし、それに対してテストケースを実行する必要があります。ここでは、単一のユニットではなく、すべてのテストシナリオでアプリケーション全体の動作をテストしています。単体テストとは、クラス内のメソッドの機能をテストすることです。単体テストでのクラスまたはメソッドのテストは、他のクラスまたはメソッドから独立している必要があります。
ただし、アプリケーションを設計するときは、単体テストを念頭に置く必要があります。そうしないと、単体テストは統合テストと同じくらい難しくなります。もちろん、単体テストではありません。
単体テストコントローラーには、統合テストよりも優れていると思いますか？
ユニットレベルでのエラーの検出と修正は、システムレベルに比べて非常に簡単です。だから答えはイエスです。
あなたの場合、コントローラーが必要以上のことを実行するアプリケーションがあると思います。したがって、単体テストを非常に真剣に考えている場合は、必要に応じて依存関係をリファクタリングして緩く結合する必要があります。それ以外の場合は、単体テストを作成してもあまりメリットはありません。