依存関係の地獄からの脱出：Mock Abuse（モックの濫用）を克服する設計戦略

テストにおけるMockの濫用、それはまるで設計の悪夢。過剰なMockは、リファクタリングを困難にし、テストスイートに対する嫌悪感を募らせ、カバレッジばかりを重視して肝心の動作検証がおろそかになるなど、様々な問題を引き起こします。開発者のコミュニティでは、Dave Farleyが「Mockery（モックの嘲り）」と呼び、Jason Gormanは「Mock Abuse（モックの濫用）」、「Mock Hell（モックの地獄）」と表現しています。 この問題を克服するための設計戦略を解説します。

なぜMock Abuseが問題なのか？：テスト駆動開発の落とし穴

Mock Abuseとは、テスト対象のコードの依存関係を過剰にMockすることです。具体的には、以下のような問題を引き起こします。

• リファクタリングの困難化: Mockが多すぎると、コードの構造を少し変更するだけで、大量のテスト修正が必要になります。
• テストスイートへの嫌悪感: 修正が頻繁に発生するテストスイートは、保守の負担となり、開発者のモチベーションを低下させます。
• 動作検証の軽視: カバレッジを追求するあまり、コードの実際の動作が正しく検証されているかを軽視してしまうことがあります。

Mock Abuseからの脱却：理想的な設計とは？

では、どのような設計がMock Abuseを回避できるのでしょうか？ Jason Gormanは、以下のポイントを挙げています。

• 関心の分離: コードを、それぞれが単一の責任を持つセクションに分割します。
• 公開APIの明確化: 各セクションが持つべき明確なAPIを定義します。インターフェースを適切に使用することを意識しましょう。
• 内部実装の隠蔽: 各セクションの内部実装（クラス数や関数数）は、外部から意識する必要がないように設計します。

依存性注入と依存性排除：より良い解決策を求めて

オブジェクト指向プログラミング（OOP）では、インターフェースやabstractといった抽象化の概念が、Mock Abuseを悪化させる可能性があります。関数型プログラミング（FP）でも同様の問題が発生する可能性はありますが、OOPほど一般的ではありません。いずれの場合も、依存性注入（Dependency Injection） を理解し、活用することが重要です。

Test Driven Development(TDD)を実践する中で、依存性を注入する際に「dependenciesが多すぎるのではないか？」という疑問を持つことが重要です。 この疑問を持つことで、よりコードを疎結合にし、依存性排除（Dependency Rejection） につながります。 つまり、OOPでは依存関係の少ないクラス/メソッドが、FPにおいては純粋関数が増えることを意味します。

設計改善の視覚化：良い設計、悪い設計

Jason Gormanは、シーケンス図を用いて、良い設計と悪い設計を視覚的に表現する素晴らしい方法を提示しています。

これらの図は、チーム全体で設計の問題点を共有し、改善策を議論する上で非常に有効です。Mockの濫用を防ぎ、テスト容易性の高い、保守性の高いコードを目指しましょう。テストの実施方法について見直し、テスト戦略の見直しを検討しましょう。