CODEWITHSUNDEEP
sqliteunit-testingsql-server-ce
user513234
user513234

Reputation:

Using SqlCe as a database and unit tests with Sqlite

At the moment I am using SqlCe as a database for my project and doing unit tests with Sqlite because of its simplicity(Such as allow to use Inmemory). I just wonder, in the future this may lead to a dispute or oddity?

Upvotes: 1

Views: 309

Answers (1)

mclark1129
mclark1129

Reputation: 7592

If using a different persistence mechanism inside of your unit tests causes you a problem, then the problem would likely be caused by:

  1. Your unit tests
  2. Your general application architecture

The tests that you write for an object should not depend on any way that their dependencies are implemented, doing so automatically means your unit tests turn into integration tests.

You should design your objects using the concept of Persistence Ignorance, which means that they are implemented in such a way so that their implementation does not depend on how the underlying datasource is implemented. A common method for achieving PI inside of enterprise applications is to use the Repository Pattern. This abstracts the interface your objects use to access the datasource from the underlying implementation of the datasource itself. What this means is, in theory, you can create new providers to different datasources without having to change the implementation of your objects that depend on them.

For example:

Let's say that you have an entity called Customer which you save inside of a SqlCe database. You could create an interface called ICustomerRepository that is implemented by a SqlCeCustomerRepository which you use inside of your main application. That way in your unit tests, you could swap it out for a SqlLiteCustomerRepository if you found that to be an easy way to create a mock datasource. To keep things even simpler, you could just create an InMemoryCustomerRepository that used List<T> under the hood to store and retrieve your objects. The point being it doesn't really matter HOW the datasource is implemented, as long as it conforms to the contract you set up on your repository interface.

The benefits of this pattern also reach beyond unit testing, and into general maintenance of your application. Suppose you want to scale up your architecture and use SQL Server instead of SQL CE, using an abstraction such as a repository would help limit the amount of change required in your system in order for this to happen, leading to less development time, less bugs, and happier customers.

Upvotes: 4

Related Questions