私は最近かなりの依存関係を抱え始めているプロジェクトに取り組んでおり、AutoMockingコンテナを使用してテストを少しきれいにして壊れにくくするという考えを探ってきました。Auto Mockingコンテナの使用は良いか悪いのですか？
私は、TDD/BDDの純粋主義者が、次のような記述をしているという話を聞いたことがあります。テスト対象で必要とされる依存関係がすぐにわかりにくく、必要のない依存関係を追加できます。どちらも、それらを使うことに対する特に強い議論のようには聞こえません。
私の見解では、必要に応じてリファクタリングして、ビジネス要件に沿った依存関係を取り除いて導入することができます。テストに戻ったり、コードをコンパイルするために新しいモック/スタブを導入する必要はありません。
AutoMockingは良い/悪い習慣と考えられますか？それを使用するべきか使用すべきではない特定の状況がありますか？
ツールやプロセスと同じように、それらを使用するのに正しい時間と不正な時間があります。銀の弾丸は何もない。 「これが私の仕事を手伝ってくれるだろうか？」と自分自身に尋ねなければなりません。そして、今日の終わりには、私たちの仕事は、できる限りのビジネス価値を提供することです。
グリーンフィールド開発を行うときは、オートロックはそれほど役に立ちません。すべてがゼロから開発されており、TDD/BDDテクニックは "伝統的な"モックを使っています。理論的には、依存関係は劇的に変化しておらず、それらが存在するときには、いつ物事を壊しているかを知ることは良いでしょう。
メンテナンスモード（または従来のコードベースを扱う）では、オートロックは非常に有益であることがわかります。たとえば、テクニカル債務の浄化を任されています。これにはおそらく多くのリファクタリングが必要になります。これらの変更からテストを分離することは、巨大な時間節約です。あなたのコードにたくさんの依存性がある場合、おそらくSOLIDとSOCが壊れているので、すべての依存性を利用しないテストがたくさんあるはずです。このため、オートロックは非常に有益です。もちろん、他の多くの例があります。
どのツールでも、松葉杖にならないようにする必要があります。 automockingを活用することで、インターフェースやapiを変更することができます。明らかにアンチパターンです。しかし、正しく使用された場合、私はそれがプロジェクトチームにとって大きなメリットであることがわかりました。
正しいシナリオでは、批判的思考とアプリケーションが必要です。
あなたの依存関係を手動で配線する（ユニットテストでは依存関係は対象オブジェクトの数が非常に少ないことに注意してください）、においがある時を知ることができます - このクラスはあまりにも大変で、切り落とすそれは、私はオートモックが悪いとは思わないと言いましたが、すべてのツールが慎重に使用されなければならないようです。
オートモックは、依存関係の匂いが始まるその時点で便利になり始めます。 Skimedicの回答とレベル別のコメントの両方が、同じ方向に向いています。だから、この練習はは避けてください。一般的にはです。ただし、あなたが遺産/技術負債を取り除くことができない場合を除きます。そのような場合でも、オートモックが存在しないように行動するほうが良いかもしれないと思っています。チームのスピードを遅くすると、経営陣は一部のリファクタが順調であると考えるように強制するもう一つの理由になります。または、それがやむを得ない遺産であれば、あなた自身の偽のビルダーをプログラムしてください。テストの追加された複雑さは、単にオートモックを使用し、明らかに簡単なテストをするよりも、「危険ゾーン」の良いマーカーになります。
そして、IMOでは、新しいコードではまったく使用しないでください。
私はオーチャードの上に構築されたプロジェクトに取り組んでおり、多くのオーチャードの良さを利用するということは、私の意見）をいくつかのクラスに依存しています。私はいくつかのファクトリを作成して、類似した依存関係を包み込み、依存関係の数を減らすことを試みましたが、それでも場所は扱いにくいです。この場合、 'AutoMocking'コンテナは、必然的に依存関係を変更することで必然的に作成される改変を削減します。 – levelnis