C# でプライベート メソッドを効果的に単体テストするにはどうすればよいですか?

プライベート C# メソッドの単体テスト: 課題と解決策

C# でプライベート メソッドを直接単体テストするのは、カプセル化のため問題があります。 Visual Studio はこれを支援するアクセサー クラスを生成しますが、プライベート リストを操作する際のオブジェクト変換エラーなどの実行時エラーが発生する可能性があります。 これは多くの場合、アクセサー クラスとターゲット クラスの間の型の不一致に起因します。

問題:

一般的なシナリオは、プライベート リストに項目を追加しようとしたときにオブジェクト変換エラーが発生し、実行中に単体テストが失敗することです。アクセサー クラスのリストの型は、元のクラスのリストの型と異なります。

問題への対処:

非推奨のアプローチ: PrivateObject クラス:

.NET Core 2.0 より前のバージョンの .NET では、PrivateObject クラスはプライベート メソッドを呼び出す方法を提供していました。

Class target = new Class();
PrivateObject obj = new PrivateObject(target);
var retVal = obj.Invoke("PrivateMethod");
Assert.AreEqual(expectedVal, retVal);

重要: PrivateObject と PrivateType は .NET Core 2.0 以降ではサポートされなくなりました。

より良い代替案:

ベスト プラクティスでは、通常、プライベート メソッドの直接テストは推奨されません。 その理由と代わりに何をすべきかは次のとおりです:

• パブリック メソッドによる間接テスト: パブリック インターフェイスのテストに重点を置きます。パブリック メソッドが正しく動作する場合、それらをサポートするプライベート メソッドも正しいと考えられます。
• テストでの状態変更を避ける: 単体テストでは、テスト対象のオブジェクトの内部状態を変更しないことが理想的です。 特定の入力に基づいて出力を検証することに集中してください。
• モック オブジェクトの使用: モッキングは、直接アクセスせずにプライベート メソッドの対話と出力をテストするための制御された環境を提供します。
• リフレクションの使用を控える: リフレクションを使用するとプライベート メンバーにアクセスできますが、複雑でエラーが発生しやすいため、単体テストには一般的に推奨されません。 テストが脆弱になり、保守が困難になります。

以上がC# でプライベート メソッドを効果的に単体テストするにはどうすればよいですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。