Effort- FirstOrDefault returns null when Faking Database

c# effort entity-framework mocking unit-testing

Accepted Answer

I'll Respond to Your Direct Question

I have two suggestions for the exact question you posed:

  1. Please review.contextx.Client.ToArray() then count up the actual number of members in that collection. It's possible that theClient If the collection is genuinely empty, you will get null. Alternatively, it can be the case that the Client collection's first entry contains a null value.EMail .

  2. If you call, how does the behaviour change?contextx.SaveChanges() prior to asking theClient the DbContext's collection? I'm interested to learn whether phoningSaveChanges will result in the new value being added into the collection. Although it shouldn't be necessary, there may be some odd interactions between the Effort and theDbContext .

EDIT:SaveChanges() proves to be the solution.

General Testing Advice

I'll provide some general unit testing advise based on my 10 years of experience as a unit testing practitioner and coach since you tagged this question with the "unit-testing" tag. Testing your application's different little components separately is what Unit testing is all about. This often implies that only a small number of classes are used by unit tests at once. Additionally, unit tests shouldn't rely on third-party libraries or dependencies (such as the database). In contrast, a integration test puts more of the system under stress at once and may be dependent on external resources like databases.

Even though this may appear like a language quarrel, the words are crucial for explaining to other team members the true purpose of your testing.

Either you are trying to test your data access layer in this situation, or you truly want to unit test some component that just so happens to rely on DbContext. You must remove the direct dependent on the DbContext if you want to construct a standalone unit test for a piece of code that relies on it. I'll explain this in the sections below in removing the DbContext dependency. Otherwise, all you're doing is attempting to integrate test your DbContext, which includes the mapping of your entities. Isolating these tests and using a true (local) database in this situation has always seemed to me to be the best option. Use a locally installed database of the same kind as the one in use in production, if possible. SqlExpress usually works perfectly. Point your tests to a database instance that they can entirely destroy. Before running each test, let your tests erase any existing data. Then, they may put up whatever data they need without worrying that it would contradict with already-existing data.

removing the DbContext dependency

How can one therefore create effective unit tests when their business logic relies on obtainingDbContext Zzz-92 Zzz

When I utilise Entity Framework in my apps for data persistence, I make sure that users have access to theDbContext is part of a different data access initiative. Usually, I'll write classes that follow the Repository pattern, and such classes are permitted to have dependencies on other objects.DbContext So, in this instance, I would develop aClientRepository that carries out anIClientRepository interface. The user interface would like the following:

public interface IClientRepository {

    Client GetClientByEMail(string email);

}

Then, using a simple stub, dummy, or whatever, any classes that need access to the method may be unit tested. There is no need to be concerned about ridicule.DbContext . You may extensively test your data access layer using a real database since it is confined. See the above for more tips on testing your data access layer.

Additionally, the use of this interface clarifies what it means to locate aClient by email address in one one location. TheIClientRepository You may easily get the solution to the question "How do we query forClient our system's entities?"

acquiring a reliance onDbContext is a testing issue of around the same size as enabling domain classes to rely on the connection string and using ADO. everything is net code. It implies that you must establish a genuine data store with actual data in it (even with a fictitious database). Nevertheless, if you limit your access to theDbContext You'll discover that writing unit tests for a particular data access assembly is significantly simpler.

In terms of project management, I normally only let my data access project to accept an Entity Framework reference. I'll define the entities in a different Core project. In the Core project, I will also define the data access APIs. The data access project is then given the actual interface implementations. Only the top-level executable or web project really has to rely on the data access project; the rest of the projects in your solution may simply accept the Core project as a dependency.

1
8/16/2016 4:10:34 PM


Related Questions





Related

Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow