[もちろん、質問は特定の「友達」の実装に限定されません。関連する場合は、実装の詳細を自由に指摘してください]
未回答の質問を読んで、私はInternalsVisibleTo属性に出くわしました：
現在のアセンブリ内でのみ通常表示されるタイプが別のアセンブリに表示されることを指定します。
MSDNのC＃プログラミングガイドには、属性を使用して別のアセンブリでメソッドと型を使用できるようにする方法を説明する[フレンドアセンブリ]セクションがあります。internal
これを使用して、単体テストアセンブリで使用するライブラリをインストルメント化するための「非表示」インターフェイスを作成するのは良い考えではないかと思います。両方向（本番アセンブリでのテストコード、テストコードでの本番アセンブリに関する詳細な内部知識）での結合が大幅に増加するようですが、一方で、パブリックインターフェイスを乱雑にすることなくきめ細かいテストを作成するのに役立つ場合があります。
テスト時に友達宣言を使用した経験は何ですか？それはあなたの銀の弾丸でしたか、それとも死の行進を始めましたか？
私はこの手法を広範囲に使用しました。これは、通常の消費者には見えないコード ライブラリの側面を単体テストでテストできることを意味します。
を使用[InternalsVisibleTo]するとカップリングが増加しますが、(マイナーな) 増加は利益に見合うだけの価値があると思います。
私の単体テストは、テスト対象のコードとすでに緊密に結合されています。通常の消費者には見えないものにアクセスすることで、特定の実装ではなく特定の結果を保証するテストを作成しようとしていますが、実装を多少制限しています。
逆に言えば、結合は最小限[InternalsVisibleTo]です。コード アセンブリに属性を持ち、一部をprivateではなく internal (またはprotectedではなくprotected internal ) としてマークします。
(ここでは、単体テストの使用によって引き起こされる設計変更を無視していることに注意してください。これは、まったく別の議論です。)
この[InternalsVisibleTo]属性では、アセンブリに厳密な名前を付ける必要があります。まだこれを行っていない場合は、厳密な名前のアセンブリが他の厳密な名前のアセンブリにのみ依存する可能性があり、最終的にいくつかのアセンブリを変更する必要が生じる可能性があるため、これが少し面倒であることに気付くかもしれません。
テスト アセンブリの公開キーを含める必要があるため、属性を正しく設定するのは少し面倒です。IDesign には、クリップボードに属性を作成して貼り付けられる便利なFriend Assembly ツールがあります。おすすめされた。
これは私が個人的に適用した唯一の使用法でInternalsVisibleToあり、実際に非常に便利です。
私は単体テストをブラックボックステストとは見なしていません。それらはすでにある程度実装に結合されています。内部のタイプとメソッドをテストできることで、より厳密な焦点（より小さなユニット）が可能になります。
InternalsVisibleToAttributeユニットテストを有効にするために使用することは完全に合理的だと思います。「ユニットテスト」の「ユニット」はクラスであり、クラスも含まれているinternalので、テストしたいと思います。 ただし、単体テストの方法は使いたくありませんprivate。
テスト専用の特別なプライベートインターフェイスを作成するのは良い考えではないと思います。単体テストの価値の1つは、クラスのコンシューマーの観点から、クラスへのインターフェースについて考える機会を与えることです。バックドアを提供すると、そのメリットが失われます。
ただし、私の好みは、単体テストを本番コードと同じアセンブリに配置することです。通常は顧客に影響を与えませんが、私にとっては物事を単純化するので、私はそれを行います。私がそうするとき、それはInternalsVisibleTo質問を去らせます。
実際、単体テストは、私が自分自身で for を使用することができた唯一InternalsVisibleToAttributeの用途です。これにより、「プライベート」メソッドの大部分を内部として実装する代わりに、それらをユニット テスト フレームワークに公開して、クラス内部の不変条件のより侵襲的なテストを行うことができます。
私はこの技術で大成功を収めました。他の方法ではアクセスできない状況でプライベート メソッドを呼び出せるようにすることで、神話上の 100% のコード カバレッジの目標に近づくことができます。
レガシ C++ コードと新しい C# コードを統合するときに別のアセンブリを使用した場合、別の正当なユース ケースが発生すると思います。
C++ アセンブリを取得して C++/CLI に変換し、C# で新しいコードを実装しました。これを行う場合、実際には公開されていない C# のクラス/メソッドには引き続き「内部」を使用し、これらをレガシー コードでフレンド アセンブリとして使用できるようにします。