Mock Abuse（モック虐待）をやめてコードを改善する方法：Jason Gormanの洞察
テストにおける「Mock Abuse（モック虐待）」は、開発者を苦しめる深刻な問題です。過剰なモックの使用は、リファクタリングの困難さ、テストスイートへの嫌悪感、そして何よりも、本質的な動作検証の軽視につながります。この記事では、Jason Gorman氏が提唱する「Mock Abuse」の解決策を、具体的な例を交えながら解説します。
Mock Abuseとは何か？なぜ避けるべきか？
Dave Farley氏が「Mockery」と呼び、Jason Gorman氏が「Mock Abuse」と呼ぶこの現象は、主に以下の問題点を引き起こします。
- リファクタリングの困難性: 変更に弱いテストコードは、保守性を著しく低下させます。
- テストスイートへの嫌悪感: 過剰なモックによる複雑なテストは、開発者のモチベーションを下げます。
- 動作検証の軽視: カバレッジ至上主義は、本来検証すべき動作を見失わせます。
解決策：良い設計とは何か？
Gorman氏によると、良い設計とは、以下の点を重視したコードです。
- 関心の分離: コードを単一の責任を持つセクションに分割します。
- 明確なAPI: 公開APIを通じて、コンポーネント間のインタラクションを定義します。
- 実装の詳細の隠蔽: 内部の実装（クラス数、関数数）は、API利用者にとって重要ではありません。
これらの原則に従うことで、コードの簡素化、テストの容易化、そして最も重要な コードの変更の容易化を実現できます。
Dependency InjectionとDependency Rejection
OOP（オブジェクト指向プログラミング）とFP（関数型プログラミング）のどちらにおいても、**Dependency Injection（依存性注入）**は重要なテクニックです。しかし、依存性を注入する過程で、「このコードは依存性が多すぎる。設計を見直すべきか？」という疑問を持つことが重要です。
この疑問から、**Dependency Rejection（依存性の排除）**という考え方が生まれます。これは、できる限りコードを純粋に保つことを意味します（OOPの場合は依存性の少ないクラス/メソッド、FPの場合はより純粋な関数）。
実践的なステップ：より良い設計への移行
「Mock Abuse」に陥っている状況から脱却するには、以下のステップが有効です。
- 現状の把握: Gorman氏のビデオにあるシーケンス図を用いて、チーム全体で問題点を可視化します。
- リファクタリング: 関心の分離、明確なAPI、実装の詳細の隠蔽を意識して、コードを段階的に改善します。
- テスト戦略の見直し: モックの数を減らし、コンポーネント間の協調動作を検証するテストを増やします。
- Dependency Injection/Rejection: 依存性を注入する過程で設計を見直し、不要な依存性を排除します。
まとめ：よりテストしやすいコードへ
「Mock Abuse」は、設計の問題を表面化させる兆候です。Gorman氏の提唱するように、良い設計原則を適用し、依存性を意識的に管理することで、よりテストしやすく、変更しやすいコードを書くことができます。コード設計の改善 は、テストの価値を高め、開発プロセス全体を効率化します。
