5

したがって、リポジトリパターンを使用するC＃のDALがあり、各リポジトリのインターフェイスがあります。これは、ADO.NET、MS SQL Server、およびストアドプロシージャの呼び出しによって支えられています。

これは、単体テストを実行するときに使用されているリポジトリをスタブ/モックアウトするのに最適です。

ただし、DAL自体の単体テストを追加したいと思います。できれば、NUnitでRhinoモックを使用してください。ただし、Rhinoがこの質問に関連してできないことを実行できるという確固たる主張ができる場合は、MoQに切り替えることを歓迎します。

ユニットテスト中にDBと通信して、DAL自体を効果的にテストしながら、DBをより「純粋」に保つことは避けたいと思います。ただし、DBと通信せずにDAL自体を実際に効果的に単体テストできない場合は、SQLServerおよび同じSqlConnectionおよびSqlCommand呼び出しと互換性のあるメモリ置換またはポータブルファイルベースの置換で可能な代替手段は何でしょうか。

同時に設計を過度に複雑にしない限り、注入を容易にするために、必要に応じてDALのリファクタリングを開いてください。リポジトリパターンを使用したDIには、すでにMicrosoftUnityを使用しています。

4

1 に答える 1

7

それらの単体テストは正確に何をテストしますか？典型的なDALコードを検討することは、実際の作業をサードパーティのデータアクセスコード（ADO.NET、EntityFramework、NHibernate）に委任すること以上のことはめったにありません。

私はADO.NETをあまり使用していませんが、このNHibernateの例で十分だと思います。

public User GetUser(int id)
{
    using (var session = sessionFactory.OpenSession())
    {
        return session.Get<User>(id);
    }
}

もちろん、コードが正しく記述されていると仮定すると、すべての依存関係（sessionFactoryつまり）はインターフェイスを介して渡されるため、スタブ化が容易になるため、単体テストを記述できます（それを実現するには多くのものをモックする必要があります） 。

純粋主義者のアプローチは、そのような単体テストを作成することです。これは、コードが実際に想定どおりに機能することを証明するもう1つのデータポイントであるためです（呼び出しGet）。ただし、このようなテストは、プロバイダーによって行われたデータベースアクセス全体をスタブ化する必要があるため、かなりコストがかかることに注意してください（sessionFactoryモックセッションを返すためにモックを作成し、その後、呼び出された呼び出しをチェックします）。

とにかく実際のデータベースとの統合テストを作成する必要があるため、これを行うのは難しい決定です（この場合は純粋主義的なアプローチに従うかどうか） 。そして、それらのテストは、あなたが書いた単体テストとまったく同じ領域をカバーしますが、実際の環境で動作します（スタブされたものではありません）。

私の経験では、単体テストDALは通常、それが提供するメリットの価値がありません。特に、単体テストのコストがかなり高く（データベース環境をスタブ化するためのコードの記述に費やす時間）、適切な統合テストスイートが存在する場合とは対照的です。

そして最後に、あらゆる種類のテストでインメモリデータベースを使用しないことをお勧めします。以下の理由により：

  • 遅いです
  • 制御が難しい可能性のあるいくつかの障害ポイントがあります（ORM構成、メモリ内データベースのセットアップ、無効なテストデータの可能性があります）
  • 統合テストを行うという誤った感覚を与えます（そうではありませんが、インメモリデータベースは実際の本番データベースとはまったく異なる動作をする可能性があります）

まったく同じデータベースをメモリにロードできない限り、分離された単体テストのバックアップを使用して、適切な統合テスト（DALテストの優先順位）に固執します（それらを書き込む余裕がある場合のみ）。

于 2012-07-31T23:23:58.047 に答える