sqlite - SqlCeをデータベースとして使用し、Sqliteで単体テストを行う

Question

現在、私はプロジェクトのデータベースとしてSqlCeを使用しており、その単純さ（Inmemoryの使用を許可するなど）のためにSqliteで単体テストを実行しています。将来、これは論争や奇妙につながる可能性があるのではないかと思います。

Answer 1

単体テスト内で別の永続性メカニズムを使用すると問題が発生する場合、問題の原因は次のとおりです。

1. ユニットテスト
2. 一般的なアプリケーションアーキテクチャ

オブジェクトに対して作成するテストは、依存関係が実装されている方法に依存してはなりません。そうすることで、単体テストが統合テストに自動的に変わります。

永続性の無視の概念を使用してオブジェクトを設計する必要があります。つまり、オブジェクトの実装が、基盤となるデータソースの実装方法に依存しないように実装されます。エンタープライズアプリケーション内でPIを実現するための一般的な方法は、リポジトリパターンを使用することです。これにより、オブジェクトがデータソース自体の基盤となる実装からデータソースにアクセスするために使用するインターフェイスが抽象化されます。これが意味するのは、理論的には、それらに依存するオブジェクトの実装を変更することなく、さまざまなデータソースに新しいプロバイダーを作成できるということです。

例えば：

CustomerSqlCeデータベース内に保存するというエンティティがあるとします。メインアプリケーション内で使用するICustomerRepositoryによって実装されると呼ばれるインターフェイスを作成できます。SqlCeCustomerRepositoryそうすれば、単体テストでSqlLiteCustomerRepository、モックデータソースを作成する簡単な方法であることがわかった場合は、それをaと交換できます。物事をさらに単純に保つために、オブジェクトを格納および取得するために内部InMemoryCustomerRepositoryで使用されるを作成することができます。List<T>重要なのは、リポジトリインターフェイスで設定したコントラクトに準拠している限り、データソースをどのように実装するかは実際には重要ではないということです。

このパターンの利点は、単体テストだけでなく、アプリケーションの一般的なメンテナンスにも及びます。アーキテクチャをスケールアップし、SQLCEの代わりにSQLServerを使用するとします。リポジトリなどの抽象化を使用すると、これを実現するためにシステムで必要な変更の量を制限し、開発時間とバグを減らすことができます。 、そしてより幸せな顧客。