Stub EF

If you want to use TDD (or any other testing approach with high test coverage) and EF together you must write integration or end-to-end tests. The problem here is that any approach with mocking either context or repository just creates test which can test your upper layer logic (which uses those mocks) but not your application.

Simple example:

Let’s define generic repository:

public interface IGenericRepository<TEntity> 
    IQueryable<TEntity> GetQuery();

And lets write some business method:

public IEnumerable<MyEntity> DoSomethingImportant()
    var data = MyEntityRepo.GetQuery().Select((e, i) => e);

Now if you mock the repository you will use Linq-To-Objects and you will have a green test but if you run the application with Linq-To-Entities you will get an exception because select overload with indexes is not supported in L2E.

This was simple example but same can happen with using methods in queries and other common mistakes. Moreover this also affects methods like Add, Update, Delete usually exposed on repository. If you don’t write a mock which will exactly simulate behavior of EF context and referential integrity you will not test your implementation.

Another part of story are problems with Lazy loading which can also hardly be detected with unit tests against mocks.

Because of that you should also introduce integration or end-to-end tests which will work against real database using real EF context ane L2E. Btw. using end-to-end tests is required to use TDD correctly. For writing end-to-end tests in ASP.NET MVC you can WatiN and possibly also SpecFlow for BDD but this will really add a lot of work but you will have your application really tested. If you want to read more about TDD I recommend this book (the only disadvantage is that examples are in Java).

Integration tests make sense if you don’t use generic repository and you hide your queries in some class which will not expose IQueryable but returns directly data.


public interface IMyEntityRepository
    MyEntity GetById(int id);
    MyEntity GetByName(string name); 

Now you can just write integration test to test implementation of this repository because queries are hidden in this class and not exposed to upper layers. But this type of repository is somehow considered as old implementation used with stored procedures. You will lose a lot of ORM features with this implementation or you will have to do a lot of additional work – for example add specification pattern to be able to define query in upper layer.

In ASP.NET MVC you can partially replace end-to-end tests with integration tests on controller level.

Edit based on comment:

I don’t say that you need unit tests, integration tests and end-to-end tests. I say that making tested applications require much more effort. The amount and types of needed tests is dependent on the complexity of your application, expected future of the application, your skills and skills of other team members.

Small straighforward projects can be created without tests at all (ok, it is not a good idea but we all did it and at the end it worked) but once a project passes some treshold you can find that introducing new features or maintaining the project is very hard because you are never sure if it breaks something which already worked – that is called regression. The best defence against regression is good set of automated tests.

  • Unit tests help you to test method. Such tests should ideally cover all execution paths in the method. These tests should be very short and easy to write – to complicated part can be to set up dependencies (mocks, faktes, stubs).
  • Integration tests help you to test functionality accross multiple layers and usually accross multiple processes (application, database). You don’t need to have them for everything, it is more about experience to select where they are helpful.
  • End-to-end tests are something like validation of use case / user story / feature. They should cover whole flow of the requirement.

It is not needed to test a feture multiple times – if you know that the feature is tested in end-to-end test you don’t need to write integration test for the same code. Also if you know that method has only single execution path which is covered by integration test you don’t need to write unit test for it. This works much better with TDD approach where you start with a big test (end-to-end or integration) and go deeper to unit tests.

Depending on your developement approach you don’t have to start with multiple types of test from beginning but you can introduce them later as your application will become more complex. The exception is TDD/BDD where you should start to use at least end-to-end and unit tests before you even write single line of other code.

So you are asking the wrong question. The question is not what is simpler? The question is what will help you at the end and what complexity fits your application? If you want to have easily unit tested application and business logic you should wrap EF code to some other classes which can be mocked. But in the same time you must introduce other type of tests to ensure that EF code works.

I can’t say you what approach will fit your environment / project / team / etc. But I can explain example from my past project:

I worked on the project for about 5-6 months with two collegues. The project was based on ASP.NET MVC 2 + jQuery + EFv4 and it was developed in incremental and iterative way. It had a lot of complicated business logic and a lot of complicated database queries. We started with generic repositories and high code coverage with unit tests + integration tests to validate mapping (simple tests for inserting, deleting, updating and selecting entity). After few months we found that our approach doesn’t work. We had more then 1.200 unit tests, code coverage about 60% (that is not very good) and a lot of regression problems. Changing anything in EF model could introduce unexpected problems in parts which were not touched for several weeks. We found that we are missing integration tests or end-to-end tests for our application logic. The same conclusion was made on a parallel team worked on another project and using integration tests was considered as recommendation for new projects.

source: ASP.NET MVC3 and Entity Framework Code first architecture

Looks like the repository pattern is solution for everything … Repository is not a silver bullet!

I’m using the repository pattern with EF everyday because when I started my current project several months ago it looked like recommended solution. My conclusions:

  • Repository makes interaction with EF much harder. Just browse questions related to EF tags and you will see what complexities must be handled directly on the context, changetracker, etc.
  • Generic repository is something that works for CRUD operations but not for real DDD scenarios. Once your repository works with aggregate roots (DDD) generic approach fails.
  • Unit testing doesn’t work at all because general idea that you will mock repository and test your upper layer without dependencies to EF and database fails once you expose IQueryable. Linq-to-entities is only subset of Linq-to-objects and mock doesn’t handle referential integrity so many times I saw green unit tests and runtime exceptions. The correct testing approach with EF are integration tests. Mocking repository is only for testing real business logic not related to data access. If you don’t have integration test for your business method accessing or persisting data you didn’t test it.
  • Exposing specialized methods like GetByXXX is just step back. Most of these methods are used only once. You will end with the code similar to repositories used for wrapping stored procedures calls. Many developers like ORM just because they can avoid such rigid architecture.

EF itself already offers repository pattern – DbSet and ObjectSet are repositories and DbContext and ObjectContext are Unit of works. So in my opinion repository pattern is overused. It can be useful in large projects where you need strict layering or in case of placing additional logic to its methods. Using repository just because you want to wrap access to EF is often valueless code and just additional layer of complexity.

You can in the same way create reusable methods defining your queries

source: repository pattern

An object with the same key already exists in the ObjectStateManager. The ObjectStateManager cannot track multiple objects with the same key


Original answer used Find instead of Local.SingleOrDefault. It worked in combination with @Juan’s Save method but it could cause unnecessary queries to database and else part was probably never executed (executing the else part would cause exception because Find already queried the database and hadn’t found the entity so it could not be updated). Thanks to @BenSwayne for finding the issue.

You must check if an entity with the same key is already tracked by the context and modify that entity instead of attaching the current one:


public override void Update(T entity) where T : IEntity {
    if (entity == null) {
        throw new ArgumentException("Cannot add a null entity.");

    var entry = _context.Entry<T>(entity);

    if (entry.State == EntityState.Detached) {
        var set = _context.Set<T>();
        T attachedEntity = set.Local.SingleOrDefault(e => e.Id == entity.Id);  
// You need to have access to key

        if (attachedEntity != null) {
            var attachedEntry = _context.Entry(attachedEntity);
        } else {
            entry.State = EntityState.Modified; // This should attach entity

As you can see the main issue is that SingleOrDefault method needs to know the key to find the entity. You can create simple interface exposing the key (IEntity in my example) and implement it in all your entities you want to process this way.

Source: ObjectStateManager