NUnit Testing of Entity Framework 4.1 and code-first

A while back I started a new project called ennf – Eddie’s Neural Network Framework. (Check it out at http://ennf.codeplex.com/) One of the things this framework brings along is an automatic storing of the networks in a database with the code-first Entity Framework 4.1  from Microsoft. Of course I wanted to create NUnit tests for the software as I’ll be developing this over years to come and when other people get into it, I’m bound to not have a complete overview over all the code. And it is a best practice anyway. 

Unfortunately Microsoft hasn’t gotten around to implementing the framework Unit-testing friendly. One blog from a Microsoft Engineer (sorry, don’t have the link anymore) in essence said “It wasn’t the first priority”.
@Microsoft: please make unit-testability a priority on your next cycle. Thanks.
That being the case, the situation leaves you with 2 options:

While Moles is a nifty idea, I ran into trouble trying to use them with Unity Framework 2.0 and the Enterprise Library. For some reason (which I didn’t research further) the unity framework suddenly didn’t work correctly anymore once I tried combining it with Moles. My guess is that the reflection somehow got messed up, but that is really just a stab in the dark. A way how to do this can be found here.

That left me with option 2 – wrapping the entity framework with my own interfaces. There are blogs aplenty around showing how to use the IDbSet interface to create unit tests. (example here or an older example here)
Be warned: that is only half the story and the blogs are quiet on anything else. Once you take that path, you end up having to slowly replace all classes with wrappers. At least if you use the Entity Framework for anything else than trivial things. The first step is to setup your T4 Templates which is fairly easy to do. And then the fun starts. First you replace the DbSet, then the DbEntityEntry and then it starts getting boring.

Well … if you want to Unit-test, then you don’t have much options. How does such wrappers look like? An example

public interface IDbMemberEntry<TEntity, TProperty> where TEntity : class
{
        TProperty CurrentValue { get; set; }
        IDbEntityEntry<TEntity> EntityEntry { get; }
        string Name { get; }

        bool Equals(object obj);
        int GetHashCode();
        Type GetType();
       ICollection<DbValidationError> GetValidationErrors();
        string ToString();
}

Code Example 1: Interface for DbMemberEntry

class DbMemberEntryAdapter<TEntity, TProperty> : IDbMemberEntry<TEntity,TProperty> where TEntity : class
    {
        private DbMemberEntry<TEntity, TProperty> _MemberEntry;

        public DbMemberEntryAdapter(DbMemberEntry<TEntity, TProperty> memberEntry)
        {
            _MemberEntry = memberEntry;
        }

        public TProperty CurrentValue
        {
            get
            {
                return _MemberEntry.CurrentValue;
            }
            set
            {
                _MemberEntry.CurrentValue = value;
            }
        }

        public IDbEntityEntry<TEntity> EntityEntry
        {
            get { throw new NotImplementedException(); }
        }

        public string Name
        {
            get { return _MemberEntry.Name; }
        }

        public ICollection<System.Data.Entity.Validation.DbValidationError> GetValidationErrors()
        {
            return _MemberEntry.GetValidationErrors();
        }
    }

Code Example 2: Implementation for DbMemberEntry

Ok, the example isn’t fully implemented, but you get the idea. The rest is just coding …

Advertisements

2 thoughts on “NUnit Testing of Entity Framework 4.1 and code-first

Add yours

  1. That’s why some people try the repository pattern or even other ORMs. I am, too, a bit disappointed that unit testing is not first priority at Microsoft. Silverlight and Windows Phone are missing unit test support, too. There are some hacks but not really good enough for production. Offering big ALM tools and ignoring unit tests for new technology feels strange.
    Btw. I am not yet convinced by code first as change management seems to be difficult. What do you think about that?

    1. Especially if it could be so easy to make it possible by defining a couple interfaces …
      I think it is the right way to go if you’re into domain-driven design. It allows for a easy way to define a Business Layer and a Data Access Layer while your at it. Of course that is one of the prices you pay with such a setup: if you create new data properties, etc. then you have to make sure they find their way through the layers.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

Up ↑

%d bloggers like this: