C#

Entity framework 7 in memory provider test

A while ago I wrote an article that http://www.codeproject.com/Articles/875165/To-Repository-Or-NOT which talked about how to test repository classes using Entity Framework and not using Entity Framework.

It has been a while and I am just about to start a small project for one of the Admin staff at work, to aid her in her day to day activities.

As always there will be a database involved.

I will likely be using Owin and OR MVC5 with Aurelia.IO for Client side.

Not sure about DB, so I decided to try out the In Memory support in the yet to be released Entity Framework 7.

Grabbing The Nuget Package

So lets have a look. The first thing you will need to do is grab the Nuget package which for me was as easy as using the Nuget package window in Visual Studio 2015.

image

The package name is “EntityFramework.InMemory” this will bring in the other bits and pieces you need.

NOTE : This is a pre-release NuGet package so you will need to include prelease packages.

 

The Model

So now that I have the correct packages in place its just a question of crafting some model classes. I am using the following 2

Person

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace EF7_InMemoryProviderTest
{
    public class Person
    {
        public Person()
        {
            Qualifications = new List<Qualification>();
        }

        public int Id { get; set; }

        public string FirstName { get; set; }

        public string LastName { get; set; }

        public ICollection<Qualification> Qualifications { get; set; }

        public override string ToString()
        {
            string qualifications = Qualifications.Any() ?
                    Qualifications.Select(x => x.Description)
                        .Aggregate((x, y) => string.Format("{0} {1}", x, y)) :
                    string.Empty;

            return string.Format("Id : {0}, FirstName : {1}, LastName : {2}, \r\nQualifications : {3}\r\n",
                        Id, FirstName, LastName, qualifications);
        }
    }
}

Qualification

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace EF7_InMemoryProviderTest
{
    public class Qualification
    {
       
        public int Id { get; set; }

        public string Description { get; set; }

        public override string ToString()
        {
            return string.Format("Id : {0}, Description : {1}",
                        Id, Description);
        }

    }
}

 

Custom DbContext

Nothing more to it than that. So now lets look at creating a DbContext which has our stuff in it. For me this again is very simple, I just do this:

using Microsoft.Data.Entity;
using Microsoft.Data.Entity.Infrastructure;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace EF7_InMemoryProviderTest
{
    public class ClassDbContext : DbContext
    {
        public ClassDbContext(DbContextOptions options)
            : base(options)
        {
        }

        public DbSet<Person> Members { get; set; }
        public DbSet<Qualification> Qualifications { get; set; }
    }
}

Writing Some Test Code Using The InMemory Provider

So now that we have all the pieces in place, lets run some code to do a few things

  1. Seed some data
  2. Obtain a Person
  3. Add a Qualification to the Person obtained

Here is all the code to do this

using Microsoft.Data.Entity;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;

namespace EF7_InMemoryProviderTest
{
    class Program
    {
        static void Main(string[] args)
        {
            var optionsBuilder = new DbContextOptionsBuilder<ClassDbContext>();
            optionsBuilder.UseInMemoryDatabase();

            using (var classDbContext = new ClassDbContext(optionsBuilder.Options))
            {
                SeedData(classDbContext);

                var personId1 = GetMember(classDbContext, 1);
                Console.WriteLine("> Adding a qualication\r\n");
                personId1.Qualifications.Add(classDbContext.Qualifications.First());
                classDbContext.SaveChanges();

                personId1 = GetMember(classDbContext, 1);


                Console.ReadLine();

            }
        }

        private static Person GetMember(ClassDbContext classDbContext, int id)
        {
            var person = classDbContext.Members.FirstOrDefault(x => x.Id == id);
            Console.WriteLine(person);
            return person;
        }


        private static void SeedData(ClassDbContext classDbContext)
        {
            classDbContext.Members.Add(new Person()
                {
                    Id = 1,
                    FirstName = "Sacha",
                    LastName = "Barber"
                });
            classDbContext.Members.Add(new Person()
                {
                    Id = 2,
                    FirstName = "Sarah",
                    LastName = "Barber"
                });

            classDbContext.Qualifications.Add(new Qualification()
                {
                    Id = 1,
                    Description = "Bsc Hons : Computer Science"
                });
            classDbContext.Qualifications.Add(new Qualification()
                {
                    Id = 2,
                    Description = "Msc : Computer Science"
                });
            classDbContext.Qualifications.Add(new Qualification()
                {
                    Id = 3,
                    Description = "Bsc Hons : Naturapathic medicine"
                });

            classDbContext.SaveChanges();
        }
    }
}

And this is the results

image

Closing Note

Quite happy with how easy this was, and I think I would definitely try this out for real.

If you want to play along, I have a demo project (for Visual Studio 2015) here:

https://github.com/sachabarber/EF7_InMemoryTest

8 thoughts on “Entity framework 7 in memory provider test

  1. Cool to see this new feature of EF, but I was always concerned about the possible mismatch between physical DB schema and the mappings.

    It’s the first time I see this provider, so I might be wrong, but it looks not that far from stubbing/mocking the repository interface. I mean, you’re still testing against a fake data store and will only be sure that your code works with this specific (in-memory) provider.

    Changing the underlying storage to, for example, MS SQL database might end up with integration errors between the code and the database. The same problem always existed with using LINQ-to-objects for tests and then switching to EF or NH LINQ providers later for real testing.

    Sure, it will at least cover things like ID generation, identity map, 1st level cache, so it’s a big step forward, but still, the tests will not make sure that the system correctly works with the real DB. So it might create some false-positives at this point 🙂

    As an alternative, an in-memory DB (SQLite?) could be used for this, but it still would only prove that it works on SQLite correctly and might fail when you switch to other DB engines.

    So, in conclusion, to me it still seems like the problem is not yet solved properly. I personally like to avoid repository abstraction and use the ORM directly, so that means I have more integration tests against real database. Yes, it is slower to run, but at least I’m sure that it works the way I want from top (my domain model, for example) to bottom most parts (DB).

    I wonder, what is Your opinion about skipping the DB testing? 🙂

    1. Yeah where you suggest using SQLLite that is another idea that works. I have also seen using the ORM directly. For example things like NHibernate have an ISession so you could just mock that stuff.

  2. we currently create services which proxy access directly to the DBContext. These proxies are interfaces so we can swap them out for In-Memory version. This is not ideal, as we have to implement a lot of the code twice (or more depending).

    what you have shown here is excellent because we “should” be able to limit the about of code we write, typically for testing purposes. Thanks for sharing!

Leave a comment