Configuration私のアドバイスは、クラスを少し再設計することです。あなたの質問は本質的に理論的なものであり、少し実用的な側面 (単体テストの失敗) があるため、私のアイデアをバックアップするためのリンクをいくつか提供します。
まず、Configuration非静的クラスを作成します。google のエンジニアである Miško Hevery は、 OO Design for Testabilityについて非常に優れたスピーチを行っており、特にテストしたい場合に、悪い設計の選択としてグローバルな状態に特に触れています。
構成はRegistryProvider、コンストラクターを介してインスタンスを受け入れることができます (依存性注入の原則について聞いたことがあると思います)。RegistryProvider責任はレジストリから値を読み取るだけであり、それが唯一のことです。をテストするときに、特定のレジストリ エントリの値をハードコードする場所Configurationを提供しますRegistryProvider stub(スタブとモックが何であるかがわからない場合は、Google で検索してください。本質的に単純です)。
さて、利点：
unit testsレジストリに依存していないので、あなたは良いです- あなたはグローバルな状態を持っていません（テスト容易性）
- あなたのテストは互いに依存していません（それぞれが別々の
Configurationインスタンスを持っています）
- テストは実行される環境に依存しません (レジストリにアクセスする権限がない場合でも、
Configurationクラスをテストすることはできます)
依存性注入が苦手だと思われる場合は、Mark Seemann の天才によって人間の魂に提供された .NET 依存性注入と呼ばれる素晴らしい芸術とエンジニアリングの作品をお勧めします。.NET 開発者向けの、クラス設計について読んだ中で最高の本の 1 つです。
私の答えをより具体的にするには：
テストごとにリフレクションを使用してクラスを再構築する必要がありますか?
いいえ、テストでリフレクションを使用しないでください (それ以外の場合に限ります)。リフレクションはあなたをテストします：
オブジェクト指向のプラクティスをカプセル化と組み合わせて使用し、実装を隠蔽します。次に、外部の動作のみをテストし、内部の実装の詳細に依存しないでください。これにより、テストは外部の動作のみに依存し、内部の実装には依存しなくなります。内部の実装は大きく変わる可能性があります。
コンストラクターではなくプロパティでレジストリをチェックするように、このクラスを再設計する必要がありますか?
私の回答で説明されているようにクラスを設計すると、クラスがレジストリにまったくアクセスしていないことをテストできます。これは単体テストの基礎です。外部システム (データベース、ファイル システム、Web、レジストリなど) に依存しないでください。レジストリにアクセスできるかどうかをテストしたい場合は、レジストリへの書き込みとレジストリからの読み取りを行う個別の統合テストを作成します。
RegistryProvider現在、コンストラクターでレジストリを読み取る必要があるか、オンデマンドでレジストリを遅延して読み取る必要があるかを判断するのに十分な情報がありません。これConfigurationは難しい質問です。しかし、私は間違いなく言うことができます-できる限りグローバル状態を避け、テストの実装の詳細への依存を最小限に抑え（これはオブジェクト指向の原則全体に関連しています）、オブジェクトを分離して、つまり外部にアクセスせずにテストするようにしてくださいシステム。次に、例外的なケースを模倣できます。たとえば、レジストリが利用できない場合、クラスは期待どおりに動作しますか? Configurationクラスの静的メンバーを介してレジストリに直接アクセスする場合、このようなシナリオを再現するのは非常に困難です。