3

アプリケーションに、ADO.NET データ プロバイダーをラップするデータ アクセス レイヤーがあります。DAL は、データ プロバイダーから返されたデータを .NET オブジェクトに変換します。DAL の単体テストに反対するようにアドバイスする投稿をたくさん見てきましたが、ループやキャスト、null チェックがたくさんあるため、多くのことがうまくいかないのではないかと心配しています。

RhinoMocks のようなものでモック DbProvider を作成することについていくつか考えましたが、各テストでモックアウトする必要があるインターフェイスの数は圧倒的であり、設定する必要がある期待の数により、テストが非常に難しくなります。読む。各テストは、テスト対象のコードよりも複雑になるようです。これは、単体テストの 3 つの目標の観点からは悲惨なことです。

  1. 可読性
  2. 保守性
  3. 信頼性

使いやすい DbProviderFactory を実装して、xml からサンプル データをロードするというアイデアがありました。テストで依存性注入を介してプラグインできました。これにより、テストの保守がはるかに簡単になります。些細な例は次のとおりです。

[TestCase]
public void CanGetCustomer()
{
    var expectedCommand = new XmlCommand("sp_get_customer");
    expectedCommand.ExpectExecuteDataReader(
        resultSet: @"<customer firstName=""Joe"" lastName=""Blogs"" ... />");

    var factory = new XmlProviderFactory(expectedCommand);

    var dal = new CustomerDal(factory);
    Customer customer = dal.GetCustomer();

    Assert.IsNotNull(customer, "The customer should never be null");
    Assert.AreEqual(
        "Joe", customer.FirstName, 
        "The customer had an unexpected FirstName.");
}

使いやすい DbProvider を使用するこのアプローチにより、DAL コードのテストが容易になると思います。次の利点があります。

  1. テスト データは xml にあり、単体テストと共にソース管理に配置できます。外部ファイルまたはテストのインラインにある可能性があります。
  2. 私は実際のデータベースを使用していないので、これによりステートフルネスの問題が解消されます。したがって、各テストの前にデータベースを既知の状態にする必要はありません。
  3. 各テストですべての ADO.NET インターフェイスをモック アウトする必要はありません。コードベース全体で再利用できる一連の偽の実装をコーディングします。

人々はこの考えに批判を与えることができますか? これに使用できる同様の実装が既にありますか?

ありがとう

4

1 に答える 1

2

データ アクセス クラス (DAL、DAC、DAO、リポジトリなど) の適切な単体テスト (いいえ、統合テストではありません) のトピックについて、多くの哲学的な議論をします。統合テストを行っているため、無意味だと主張する人もいます。無視されがちなこれらのコード単位の単体テストには、非常に大きな価値があります。まず、データ アクセス クラスを適切に単体テストするには、正しく構造化されている必要があり、コンシューマーが対話できる砂の中に線を引く必要があります (インターフェイスを考えてください)。データ アクセスの実装には、使用するアプリケーション コードのみが依存するインターフェイスを定義する必要があります。選択したインフラストラクチャ コード (ADO.NET、NHibernate、NDatabase など) には、データ アクセス コードのみが依存するインターフェイスが必要です。これらのインフラストラクチャ インターフェイス (IDBConnection、ISession、IDatabase など) が利用可能で正しく活用されていれば、選択したモッキング ツールを使用して、単体テストでこれらのインターフェイスをモックできます。これにより、単体テスト (インフラストラクチャ インターフェイスのモック)、統合テスト (REAL データベースに対するテスト) が行われ、全体的にネット結合が低い高品質のデータ アクセス コードが得られます。

1 つのメモ: 私の意見では、データ アクセス関連のコードがデータ アクセス (または永続化) レイヤーを通過したときに、注意すべき悪いコードの匂いがします。たとえば、接続、コマンド、セッションなどがデータ アクセス クラスの実装よりも高いレベルで使用されている場合、これは関心の分離に違反していると思われます。

于 2011-05-21T04:35:21.303 に答える