だから私はSOLID（と混合）WritingTestableCodeと呼ばれるこのことについて読んだ。そして具体的にはD部分について。言語ライブラリによって提供されるプリミティブ型またはメソッド/クラスを使用する場合、これらのガイドラインにどのように従うのでしょうか。
配列（java（new int[64]）またはFileWriterなどのクラスメンバー）に依存性注入を使用する必要もありますか？これらはDIを使用して注入する必要がありますか、それともクラスはそれらをインスタンス化できますか？
上記のガイドラインに従うためにどこまで行けばよいですか？
私は言語固有の答えを探していません（可能であれば）。私見では、答えは、たとえば、PHP、Python Java、一体、さらにはCにも当てはまるはずです。
通常、プリミティブやDTO / POJOのようなオブジェクトを注入することはありません。理由は次のとおりです。
FileWriter上記の点とは正反対なので、違います。テストで単純にスタブして、いくつかの強い仮定なしに機能させることはできません。たとえば、このコードを実行する将来の開発者はすべて、自分のマシンに特定のファイルがあると思います。これは通常、単体テストには使用できず、そのような場合にDIが適用される理由の1つです。
これらの問題は、アプリケーションとファイルシステムという2つの無関係なコンポーネント間の通信ポイントFileWriterとして機能するという事実に起因します。ほとんどの場合、この種の統合（アプリとDB/ネットワーク/ファイル/RESTなどの間）を行うクラスはすべて抽象化して挿入する必要があります。
配列の注入はやり過ぎです。ファイルライターを挿入することは絶対に必要です。実際、ライターを注入するだけでは十分ではありません。ファイルライターは外の世界と頻繁にやり取りしますが、それは望ましくありません。ファイルライターは独自のクラスにラップする必要があり、直接呼び出さないでください。
代わりに、FileWriterWrapperのインターフェイスを挿入します。したがって、依存関係が制御されます。さらに、単体テストでのファイルの相互作用は大きな問題です。絶対に避けてください。データベースの相互作用についても同じことが言えます。実際、ユニットテストでは、外界とのすべてのやり取りをスタブ/モックする必要があります。
美しさは、SOLIDの設計とテスト容易性が密接に関連していることです。優れた設計とは、テスト可能なコードを意味します。一部のコードをテストするのが難しい場合は、通常、設計に欠陥があることを示しています。