There are several options. In this article we will list the options we know of and any crazy ideas we might have.
Desirata
- We want the application code to use EntityFramework as if nothing had changed.
- The "database" must be seeded with some initial data, and if possible, any views and stored procedures.
- The "database" should behave "similarly" to the production database.
- We must be able to query this database in the tests in order to verify the results.
- It may be nice to have EntityFramework tell us what it has saved to the database, instead of having to query the db.
- The tests using this database must setup and teardown fast, otherwise they won't run fast.
Options
EntityFramework's InMemory provider (not recommended)
Even Microsoft's documentation say this is not recommended.
SQLite
EntityFramework has great support for SQLite and any required modifications to EntityFramework's model can be applied in the test project.
If you have an existing .db file, you can copy it for each test, or maybe even open the original file in one connection, then for each test, open a new db in memory and copy the db from the file connection into the new memory db. That might be a touch faster.
Disadvantage: This isn't the database technology used in production.
TestContainers
TestContainers can be used to create a docker container per-test, so you can use a real SQL database.
Disadvantage: This is probably slower.
LocalDb
If the production db is SQL Server, then we could use LocalDb for testing. LocalDb is a version of SQL Server that runs in the user's session. It comes with Visual Studio, but can be installed independently.
LocalDb can be used to open a .mdf file directly, and we can make a copy for each test.
This should be faster than TestContainers, and may compare favourably to sqlite.
Disadvantage: It requires LocalDb to be installed. So maybe we need to use TestContainers at least for test run on CI.
Conclusion
This article is about collecting ideas, and may be updated later.
Top comments (0)