私は最近、依存関係がかなり大きくなり始めたプロジェクトに取り組んでおり、AutoMockingコンテナーを使用してテストを少しクリーンアップし、脆弱性を減らすというアイデアを模索しています。
TDD / BDDの純粋主義者がそれらを使用することに反対する議論を聞いたことがあります。たとえば、テスト対象にどの依存関係が必要かはすぐにはわかりません。または、本当に必要のない依存関係を追加できます。どちらも、それらを使用することに反対する特に強い議論のようには聞こえません。
私の見解では、1つを導入すると、必要に応じてリファクタリングし、ビジネス要件に沿って依存関係を削除して導入できます。コードをコンパイルするためだけにテストに戻って新しいモック/スタブを導入する必要はありません。
AutoMockingは良い/悪い習慣であると考えられていますか？使用すべきまたは使用すべきでない特定の状況はありますか？
他のツールやプロセスと同様に、それらを使用するのに正しい時間と間違った時間があります。特効薬はありません。「これは私の仕事を成し遂げるのに役立ちますか？」と自問する必要があります。そして、私たちの一日の終わりに、私たちの仕事は、私たちができる限りのビジネス価値を提供することです。
グリーンフィールド開発を行う場合、自動モッキングはそれほど役に立ちません。すべてがゼロから開発されており、「従来の」モックを使用したTDD/BDD手法が最適です。理論的には、依存関係はそれほど劇的に変化していません。依存関係が変化している場合は、いつ物事を壊しているのかを知ることはおそらく良いことです。
メンテナンスモード（またはレガシーコードベースを処理する）の場合、自動モックは非常に有益であることがわかります。たとえば、あなたは技術的負債を片付ける任務を負っています。これにはおそらく多くのリファクタリングが含まれ、これらの変更からテストを分離できることは非常に時間の節約になります。コードに多くの依存関係がある場合は、おそらくSOLIDとSOCを壊していることに注意してください。また、すべての依存関係を利用しない多くのテストを行う必要があります（または少なくともそうする必要があります）。したがって、この場合の自動モックは非常に有益です。もちろん、それが役立つ例は他にもたくさんあります。
他のツールと同様に、松葉杖にならないようにする必要があります。オートモッキングを活用してインターフェイスとAPIを変更できるようにすることは、明らかにアンチパターンです。しかし、正しく使用すると、プロジェクトチームにとって大きなメリットになることがわかりました。
正しいシナリオでの批判的思考と応用が必要です。
依存関係を手動で配線する（ユニットテストでは、依存関係は非常に少数のサブジェクトオブジェクト（1つ）に対するものである必要があることに注意してください）は、匂いがするときに通知します-このクラスは非常に大きいため、削減する必要があります。とはいえ、自動モックは悪いとは思いませんが、他のツールと同様に注意して使用する必要があります。
自動モックは、依存関係の匂いがし始めたその時点で便利になり始めます。スキメディックによる回答とレベニスによるコメントはどちらも同じ方向を示しています。したがって、レガシー/技術的負債を取り除くことができない場合を除いて、この慣行は一般的に避ける必要があります。そのような場合でも、自動モックが存在しないように振る舞うほうがよいと思います。チームの速度の低下が、経営陣に何らかのリファクタリングが適切であると考えさせるもう1つの理由になります。または、それが避けられない遺産である場合は、独自の偽のビルダーをプログラムします。テストの複雑さが増すと、単に自動モックを使用して明らかに単純なテストを行うよりも、「危険ゾーン」のより良いマーカーになります。
そして、IMO、新しいコードではまったく使用しないでください。