Since this video came out, Microsoft actually recommend against in memory databases for testing. Best thing to do is to mock out the repository when unit testing and use a docker image when you want to test the interaction with the database. Hope this helps
I think in-memory DBs are useful for testing Repositories and as you mentioned for integration with the DB we should use integrations tests, duh :D I really liked this video, but can you please also provide the source code?
I never thought of providing the source code to be honest 😅 I’ll make sure I provide a link to the source code in the description for future videos and will add it to this one as soon as I can!
You have to take into account that an in memory database won’t do anything more than put data there. It won’t check for relational integrity and doesn’t check database validation. So it all depends on what you’re test is doing. If you’re just using it to check simple logic then a in memory database is a nice option. If you’re writing tests that actual check the interaction with the database (integration tests, repository tests) then I would avoid in memory databases.
This is good information. In-Mem is appropriate to test Repositories. Which is 90%. Custom data methods are tested in integration tests. I agree.
I think it is worth noting that In-Mem is also very good for teaching or demoing code.
What was alternative to in memory database testing then?
Since this video came out, Microsoft actually recommend against in memory databases for testing. Best thing to do is to mock out the repository when unit testing and use a docker image when you want to test the interaction with the database.
Hope this helps
I think in-memory DBs are useful for testing Repositories and as you mentioned for integration with the DB we should use integrations tests, duh :D
I really liked this video, but can you please also provide the source code?
I never thought of providing the source code to be honest 😅
I’ll make sure I provide a link to the source code in the description for future videos and will add it to this one as soon as I can!
So, a in-memory database will not be a problem, as long as it is just used to unit test, and not for integration test?
You have to take into account that an in memory database won’t do anything more than put data there. It won’t check for relational integrity and doesn’t check database validation.
So it all depends on what you’re test is doing. If you’re just using it to check simple logic then a in memory database is a nice option. If you’re writing tests that actual check the interaction with the database (integration tests, repository tests) then I would avoid in memory databases.