.net - NUnit を使用した app.config ファイルの単体テスト

Question

app.config ファイルの値に依存するアプリケーションの単体テストを行っているときはありますか? これらの値が正しく読み取られていること、および構成ファイルに入力された誤った値にプログラムがどのように反応するかをどのようにテストしますか?

NUnit アプリの構成ファイルを変更しなければならないのはばかげていますが、テストしたい app.config から値を読み取ることができません。

編集：おそらく明確にする必要があると思います。ConfigurationManager が値を読み取れないことは心配していませんが、読み取った値にプログラムがどのように反応するかをテストすることに関心があります。

score 46 · Accepted Answer

私は通常、機能がほとんどない独自のファサードクラスで構成ファイルを読み取るなど、外部の依存関係を分離します。テストでは、実際の構成ファイルの代わりに実装して使用するこのクラスのモックバージョンを作成できます。これには、独自のモックアップを作成するか、moq や rhino モックなどのフレームワークを使用できます。

そうすれば、最初に xml 構成ファイルを作成する複雑なテストを作成することなく、さまざまな構成値でコードを簡単に試すことができます。通常、構成を読み取るコードは非常に単純であるため、テストはほとんど必要ありません。

score 31 · Accepted Answer

テストセットアップでは、実行時に構成セクションを変更できます。例えば：

// setup
System.Configuration.Configuration config = 
     ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None);
config.Sections.Add("sectionname", new ConfigSectionType());
ConfigSectionType section = (ConfigSectionType)config.GetSection("sectionname");
section.SomeProperty = "value_you_want_to_test_with";
config.Save(ConfigurationSaveMode.Modified);
ConfigurationManager.RefreshSection("sectionname");

// carry out test ...

もちろん、これをよりエレガントに行うために独自のヘルパーメソッドを設定することもできます。

score 26 · Accepted Answer

ConfigurationManager.AppSettings の set メソッドを呼び出して、その特定の単体テストに必要な値を設定できます。

[SetUp]
public void SetUp()
{
  ConfigurationManager.AppSettings.Set("SettingKey" , "SettingValue");
  // rest of unit test code follows
}

単体テストが実行されると、これらの値を使用してコードが実行されます

score 16 · Accepted Answer

クラスapp.configを使用して、ファイルの読み取りと書き込みの両方を行うことができますConfigurationManager

score 11 · Accepted Answer

私はweb.configで同様の問題に直面していました....興味深い解決策を見つけました。構成読み取り機能をカプセル化できます。たとえば、次のようになります。

public class MyClass {

public static Func<string, string> 
     GetConfigValue = s => ConfigurationManager.AppSettings[s];

//...

}

そして、通常使用

string connectionString = MyClass.GetConfigValue("myConfigValue");

ただし、単体テストでは、次のように関数を「オーバーライド」して初期化します。

MyClass.GetConfigValue = s =>  s == "myConfigValue" ? "Hi", "string.Empty";

それについての詳細：

http://rogeralsing.com/2009/05/07/the-simplest-form-of-configurable-dependency-injection/

score 3 · Accepted Answer

より洗練された解決策は、構成設定自体で単純な古い依存性注入を使用することです。IMHOこれは、構成読み取りクラス/ラッパーなどをモックする必要があるよりもクリーンです。

たとえば、クラス "Weather" が機能するには "ServiceUrl" が必要だとします (たとえば、天気を取得するために Web サービスを呼び出すとします)。その設定を取得するために構成ファイルに積極的に移動するコード行をいくつか持つのではなく (そのコードが Weather クラスにあるか、他の応答のいくつかに従ってモックできる別の構成リーダーにあるかに関係なく)、Weather クラスは許可できます。コンストラクターへのパラメーターを介して、または場合によってはプロパティセッターを介して注入される設定。そうすれば、単体テストは非常に単純かつ直接的になり、モックを作成する必要さえありません。

設定の値は、制御の反転 (または依存性注入) コンテナーを使用して注入できます。そのため、Weather クラスのコンシューマーは、コンテナーによって処理されるため、どこかから値を明示的に指定する必要はありません。

score 2 · Accepted Answer

それは私のために働いた：

 public static void BasicSetup()
  {
     ConnectionStringSettings connectionStringSettings = 
          new ConnectionStringSettings();
     connectionStringSettings.Name = "testmasterconnection";
     connectionStringSettings.ConnectionString = 
          "server=localhost;user=some;database=some;port=3306;";
     ConfigurationManager.ConnectionStrings.Clear();
     ConfigurationManager.ConnectionStrings.Add(connectionStringSettings);
  }

score 1 · Accepted Answer

インターフェイスで読み取りビットをいつでもラップし、構成ファイルから特定の実装を読み取ることができます。次に、モックオブジェクトを使用してテストを作成し、プログラムが不正な値をどのように処理したかを確認します。個人的には、これは .NET Framework コードであるため、この特定の実装をテストするつもりはありません (そして、MS が既にテストしていることを願っています)。

score 1 · Accepted Answer

System.Configuration.Abstractions は、この種のものをテストすることになると素晴らしいものです。

ここにいくつかの良い例がある GitHub プロジェクトサイトがあります:ここにリンクの説明を入力してください

NuGet サイトは次のとおりです: https://www.nuget.org/packages/System.Configuration.Abstractions/

ほとんどすべての .NET プロジェクトでこれを使用しています。

score 0 · Accepted Answer

私は同じ問題を抱えていました、

Nunit-console.exe c:\path1\testdll1.dll c:\path2\testdll2.dll を使用できます

両方の dll が testdll1.dll.config と testdll2.dll.config などの異なる app.config を指している場合でも、これは正常に機能します。

Nunit プロジェクト構成を使用してこれら 2 つの dll をラップする場合、2 つの構成を持つ方法はありません。

Nunit プロジェクトが Project1.nunit と同じ場所にある project1.nunit の場合、project1.config が必要です。

お役に立てれば

score 0 · Accepted Answer

最も簡単なオプションは、構成を読み取るメソッドをラップして、テスト中に値を代入できるようにすることです。構成の読み取りに使用するインターフェイスを作成し、そのインターフェイスの実装をコンストラクターパラメーターとして渡すか、プロパティとしてオブジェクトに設定します (依存性注入/制御の反転を使用する場合と同様)。運用環境では、構成から実際に読み取る実装を渡します。テスト環境では、既知の値を返すテスト実装を渡します。

テスト容易性のためにコードをリファクタリングするオプションがなく、まだテストする必要がある場合、Typemock Isolator は .NET Framework 構成クラスを実際にモックする機能を提供するため、「次回はそのようなものを求めるときに、そのようなものを求めることができます。そのような appSettings 値は、この既知の値を返します。」

score 0 · Accepted Answer

実際、さらに考えてみると、自分のプロジェクトで使用する ConfigFileReader クラスを作成し、それを単体テストハーネスで偽装する必要があるのではないでしょうか?

それは普通のことですか？

.net - NUnit を使用した app.config ファイルの単体テスト

13 に答える 13

Related

Reference