{"id":241,"date":"2024-09-07T23:39:01","date_gmt":"2024-09-08T02:39:01","guid":{"rendered":"https:\/\/eliasdc.dev\/?p=241"},"modified":"2024-09-08T09:36:59","modified_gmt":"2024-09-08T12:36:59","slug":"want-better-unit-tests-with-in-memory-databases","status":"publish","type":"post","link":"https:\/\/eliasdc.dev\/index.php\/2024\/09\/07\/241\/","title":{"rendered":"Want Better Unit Tests with In-Memory Databases?"},"content":{"rendered":"\n
Developing .NET applications that interact with relational databases requires robust unit tests. While mocking is a common approach, it may not always accurately represent real-world database behavior. Using in-memory databases like SQLite for these tests offers several advantages:<\/p>\n\n\n\n
\n
Realism:<\/strong> By using an in-memory relational database, the test environment more closely resembles a production environment, allowing for more realistic testing of database interactions.<\/li>\n\n\n\n
Isolation:<\/strong> Each test has its own isolated database, eliminating dependencies on external environments.<\/li>\n\n\n\n
Cost:<\/strong> Eliminates the need for commercial database licenses.<\/li>\n\n\n\n
Simplicity:<\/strong> Easier to set up compared to a full-fledged database.<\/li>\n\n\n\n
Concurrency:<\/strong> Multiple developers can execute tests simultaneously without conflicts due to the isolation of each test.<\/li>\n<\/ul>\n\n\n\n
It’s important to note that unit tests with in-memory databases do not replace integration tests but complement your testing strategy. <\/p>\n\n\n\n<\/figure>\n\n\n\n
In this article, we’ll explore:<\/p>\n\n\n\n
\n
SQLite Challenges:<\/strong> Let’s use in-memory SQLite and highlight its limitations compared to a full relational DBMS.<\/li>\n\n\n\n
Best practices:<\/strong> How to write effective unit tests with in-memory databases and how to combine them with mocking to simulate external dependencies.<\/li>\n\n\n\n
Practical example:<\/strong> A .NET API with adaptable configuration, using SQLite for testing and a relational database (SQL Server) in a production environment.<\/li>\n<\/ul>\n\n\n\n
SQLite is a lightweight and fast database, but it has its limitations.<\/p>\n\n\n\n
\n
Data Types:<\/strong> It doesn’t support all data types found in larger databases. For example, JSON can be problematic.<\/li>\n\n\n\n
Advanced Features:<\/strong> It lacks features like partitioning, complex indexes, and distributed transactions, which are essential for more complex applications.<\/li>\n\n\n\n
Scalability:<\/strong> It may struggle with large volumes of data and complex queries.<\/li>\n<\/ul>\n\n\n\n
Best Practices <\/strong><\/h2>\n\n\n\n<\/figure>\n\n\n\n
\n
Tools and Frameworks:<\/strong> Use tools like Entity Framework Core or Dapper to simplify database configuration and interaction. In our example, we’re using Entity Framework Core, and when instantiating the context, we pass an option specifying where it should point (to the in-memory database or an external database). See the context class for an example of SQLite in-memory and SQL Server:<\/li>\n<\/ul>\n\n\n\n
Context class:<\/strong> (used in all examples and in the API that will be made available in this post)<\/p>\n\n\n\n
![\"\"](\"https:\/\/eliasdc.dev\/wp-content\/uploads\/2024\/09\/hmmm.gif\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/eliasdc.dev\/wp-content\/uploads\/2024\/09\/Challange.gif\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/eliasdc.dev\/wp-content\/uploads\/2024\/09\/Go-horse-Process-1024x727.webp\")
<\/figure>\n\n\n\n