Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
using In Memory Database not working nicely with ASP.Net Core TestServer and Startup.cs #5150
Note: I have unit tests working with an InMemoryDatabase. This is different :)
So I made sure setting up the database is different in my integration tests (using a Test*Startup.cs overriding a method).
When booting the app, it breaks on several levels. I have posted the code below and marked the lines with comments so I can refer to them. (I have tried multiple things)
Running the app with above, results in:
Which is triggered by
Ok, so perhaps all this is not needed for an InMemoryDatabase. Who needs to run migrations anyway. :)
When turning that off it will break on creating a
I'm a bit confused though. I would not expect anything like this to pop-up. Especially since running a simple Unit Test and storing (and retrieving) stuff seems to work.
Running the web app with an In Memory Database - not as an integration test
So before I digg (much) deeper into the rabbit hole I decided to put up a question here.
I was expecting to just be able to boot the application, but apparently I am missing something (or is the InMemoryDatabase not suited for integration testing?).
Any clues would be much appreciated! Thanks!
For now this is sufficient, but it does not solve the actual problem.
For me, I want to run integration tests and run them isolated. Using Sqlite I can do this. I can get rid of the DB files and run tests again. I also don't need a separated DB instance. Other ways would be to use a different Schema (on same DB instance).
@stefanhendriks The first two errors are, as you said, because the code is trying to use relational-specific functionality with a non-relational database. I believe there is now a better exception message for this, and not just the "no service registered" message.
The third issue looks like a dupe of #4285 which is fixed in the current code base.
referenced this issue
Apr 25, 2016
Just to build on @ajcvickers comments - InMemory is not intended to be a relational database. As with anything that is used with as a substitute for testing, the ability for it to replicate the behavior of the actual database you ultimately target is limited. InMemory gets you a step closer than creating test doubles for the context etc. You can also use SQLite with in-memory mode to replicate something closer to SQL Server, but ultimately even that is going to behave differently in some cases.
Thanks for responding.
From a testing POV I would expect an InMemory database atleast to have stubbed all mechanics (dependencies), even though they would not do anything. But perhaps it should be explicitly enabled somewhere? So atleast as a tester you are making the explicit choice to use a 'fake database'. (which is a step further than "in Memory" - which you could literally just see as a DB stored in memory , not in files).
Improving on the Exception message is good. I think that will prevent confusion. However, if possible, I would suggest to just give a stubbed IRelationalConnection and what not.
In my case I would not even do much DB specific stuff in this test. I would simply visit a page (GET). And I also wanted to test if my POST worked. I noticed some binding failures earlier on and wanted to make sure it kept working (hence the integration test). Especially related to Culture settings (for parsing Datetime, etc) and validations. I don't want to run UI tests (they are too fragile).
If there are other ways to do this, that would also be fine. For now I have found a good solution:
@rowanmiller I tried your suggestion for an In memory SQLite db. And it worked like a charm, although I had to do:
open a connection before running
I'm aware it is not the same as SQL Server, but thats also not the problem area in my test. (I'm not doing any (complicated) DB interactions).
I will wrap this up in a blog post for future reference, although things will probably change a bit in RC2.
I think for folks that want something that behaves like a relational database, SQLite in in-memory mode is the right thing for us to recommend... as we pad out our docs I'll make sure that we make that clear. We could make InMemory look more like a relational database - but as we enable non-relational data stores it becomes less clear that it would be a good idea. For some APIs (such as
@rowanmiller makes sense.
As said, I have written a blog post. Hope it is any good :) -> http://www.stefanhendriks.com/2016/04/29/integration-testing-your-dot-net-core-app-with-an-in-memory-database/
referenced this issue
Jul 14, 2016
Initially, I tried using
@stefanhendriks Your idea of overriding the
@RehanSaeed I also have my
As you can see I do this before calling the