Show how to test keyless entity type mapped to view

[p-m-j]

Adding to DbSet properties is easy, but it's not clear how one should test for DbQuery properties e.g. mapped to a view.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: c95e5c7e-882f-76f7-5301-2a5d1ede39d3
• Version Independent ID: 8754aa99-67a7-98ac-a51e-0ba995f96414
• Content: Testing with InMemory - EF Core
• Content Source: entity-framework/core/miscellaneous/testing/in-memory.md
• Product: entity-framework
• GitHub Login: @rowanmiller
• Microsoft Alias: divega

[ajcvickers]

@rustybox Can you provide some mode details on what you mean by "test for DbQuery properties" and what is different here when compared to DbSet properties?

[p-m-j]

Absolutely,

So I am writing some tests for service layer which queries and maps entities from a DbContext into DTO's.

With DbSet and InMemory database I can easily add records to the context and save changes before I call my system under test or make any assertions.

I have a DbQuery which maps to a sql view, I would like to setup my test such that some stub data is returned for that property which allows the rest of the method to execute allowing me to assert that the DTO's are mapped correctly.

I'm not sure the best way to do this, best I can think of is to conditionaly alter the OnModelCreating so that the property points to an collection of objects instead of calling modelbuilder.Query.ToView

[jons]

I have the same issue. A method in an AspNetCore controller that I want to unit test retrieves and does work on database records via a DbQuery, belonging to a DbContext that is injected into the Controller during test setup. There does not seem to be any mechanism (using In-Memory database rather than e.g. Moq) to ensure that there will be records to retrieve from the DbQuery. You cannot ExecuteSqlCommand() to do an INSERT, and you cannot call Add() on either the DbContext or the DbQuery for Foo objects.

I could add a layer of abstraction between controller and database context, however I would still have to use mocks with that; it would defeat the purpose of In-Memory database. The most convenient solution along these lines that I have found so far is this project: https://github.com/huysentruitw/entity-framework-core-mock

I could give up on DbQuery entirely and use DbSet, but I believe that would force me to write another DbContext for testing only, preventing me from testing the DbContext in the production code upon which EF migrations are built: I cannot risk running a migration on the table for Foo records, because this piece of software isn't its "owner." However, I do want joins across PostgreSQL schemas (I hope LINQ actually does this? Haven't confirmed yet) so I do need this DbQuery in the same DbContext as other DbSets that this project does "own."

[asifhafeez]

I have exactly the same problem. Not sure why there isn't a simple way to do this.

[chrispaynter]

As per mentioned above, I also found entity-framework-core-mock does work well in the absence of support in the In Memory context.

[duckwaffle]

I've also run in this problem, which I resolved using entity-framework-core-mock, but I figured I would throw my two cents in with a suggestion.

When using a InMemoryDbContextOptionsBuilder there could be an extension method that allows you define what a DbQuery<T> does using either by

• An expression which will allow you emulate a view SQL statement using LINQ
• Or just returning an IEnumerable<T> like entity-framework-core-mock allows you to do

Imo I think option 1 would be "better", and since option 2 already exists in a nuget package, and also kind of breaks the in memory context by having potentially unrelated entites, its probably not really worth pursuing.

[akousmata]

@duckwaffle

I've also run in this problem, which I resolved using entity-framework-core-mock https://github.com/huysentruitw/entity-framework-core-mockl <--

Your Github link is broken, I think it's got an extra 'l' at the end.

[Griind]

I have the same problem. Is there a solution to test DbQuery without using entity-framework-core-mock?

[HutchZechariah]

Trying to piece together the mean issue here, sounds like there is an issue mocking returned data from the query. In that case just Use a property of IEnumberable instead.. like this..

private DbQuery<SomeObject> SomeObjQuery{ get; set; }
public virtual IEnumerable<SomeObject> SomeObjectView => this.SomeObjQuery;

Mock the return of SomeObjectView

@duckwaffle looks like he was mentioning this though.

[chrispaynter]

After upgrading to EF Core 3.1, I now get the following error from the unit test that I was leveraging entity-framework-core-mock for.

Method 'ExecuteAsync' in type 'EntityFrameworkCoreMock.DbAsyncQueryProvider`1' from assembly 'EntityFrameworkCoreMock.Shared, Version=1.0.0.20, Culture=neutral, PublicKeyToken=null' does not have an implementation.

The developer released a entity-framework-core3-mock version that I was hoping would fix it, but did not.

The upgrade to .NET Core / EF 3.x took so much time that I'm going to disable the test for now (I only have one SQL view / DbQuery that needs to be mocked for testing, so can accept this for now).