ライブラリの「コア」セットの作成を担当する誰かが、ロギング、監査、および一般的なデータベースアクセスメソッドからのあらゆる種類のユーティリティを提供する静的クラスのセットを作成しました。
個人的には、これらのクラスをモック/スタブしたり、コンストラクターにインジェクションしたりできないため、テストが難しいライブラリのコアセットがあるため、これは悪臭を放つと思います。
TypeMockを使用してこれらをスタブ化できると思いますが、無料で実行したいと思います。
どう思いますか？
編集
それらをテストするのが難しいと思わない場合は、それらをテストする方法の例を挙げてください。これらの静的クラスは、他の型をインスタンス化してそれらの機能を実行します。
静的クラス (メソッド) は、隠れた依存関係がない限り、必ずしも避ける必要はありません。もちろん、依存関係を静的メソッドに渡すこともできます。内部に格納して、後の呼び出しの動作を変更するべきではありません。
この場合も、それらをテストするのに問題はないはずです。
しかし、あなたが言及したケースについても悪い予感がします。私はこれらの静的な「ラッパー」ユーティリティクラスのいくつかを知っています-そしてほとんどの場合、それらは本当に悪臭を放ちます:)
編集：
多分私は明確にする必要があります。静的クラス/メソッドは、非常に小さな識別タスクにのみ使用します。静的クラスが依存関係の初期化を開始する場合、それらは確実に回避する必要があります。これらの静的クラスをテストできない場合、それらはすでに大きな仕事を抱えています。
この質問の最初の回答には、あなたが言及した静的クラスに対する引数があります。
依存性注入を利用するためにこれらの静的クラスを変更するのはどれほど難しいでしょうか？DIをオプションにすると（可能な場合）、基本的に、「通常の」動作を変更せずに、DIを適切に実行するだけで、静的クラスをモックに使用できる状況を作ることができます。