What’s Best for Unit Testing in EF? It depends, dude!

This tweet stopped me in my tracks because I couldn’t reply in a tweet:

Stephen Coulson @sdcoulson

@julielerman In your opinion what is the best solution for unit testing#EF dependent code?#MockingFramework? #SQLCE? or other?

It’s a loaded question so I’ll just answer briefly.

First: it depends! 🙂 It always depends.

Do you mean unit tests or integration tests? A unit test shouldn’t be hitting a database.

FAKING FOR UNIT TESTS

I use fakes to avoid hitting a database when I truly want to do a unit test on code that’s trying to do data access. I (and many others) have written extensively about faking with EF. I have some old blog posts and book chapters that do this with EF4 but not using code first or dbcontext.

In my DbContext book I have some examples of faking with DbContext (ala EF4.1 & EF5).

I have a module in one of my Pluralsight courses on testing with EF (Entity Framework in the Enterprise).

MOCKING FRAMEWORKS FOR UNIT TEST

I’ve had a hard time finding good current examples of using mocking frameworks with EF. Typemock has one that’s terribly outdated and not useful. I found one person who’s written a little about using Moq with EF.

SQL CE FOR INTEGRATION TESTS

Sure you can use SQL CE. It’s a perfectly good way to go. Here’s a blog post by Eric Hexter to get you started:

Using sql compact for integration tests with entity framework

CODE FIRST DATABASE INITIALIZATION FOR INTEGRATION TESTS

This is what I use. One of the intializers is “DropCreateDatabaseAlways”. I use that combined with some seed data to refresh my database for each integration test. This is one of the methods I show in my Pluralsight course.

More More More!

There are plenty of other ways to go as well. For example, Lynn Langit has pointed me via twitter to ApprovalTests.

And just watch the comments fill up with other suggestions.

Hope this helps, Stephen! 🙂

  Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!  

13 thoughts on “What’s Best for Unit Testing in EF? It depends, dude!

  1. i use the effort framework for in memory entity framework integration tests. works the same as real db access, but much much faster and not persistent.

    its a bit buggy and not really finished, but has shown great progress the past year.

  2. Thanks for the amazingly prompt response Julie! I have read chapter 24 in your book "Programming Entity Framework" and I’ve setup a project using fakes. It works brilliantly but is very laborious. I’ve been watching the Pluralsight videos on Unit Testing and wondered how well mocking frameworks worked with EF to reduce dev time. I also got reading this article http://www.codeproject.com/…/Two-strategies- on code project regarding ‘Effort’ and ‘SQL-CE’ (which is technically an integration test). Was wondering what your take on this was 🙂 Thanks again for the reply.

  3. As part of a longer project, I walked through some of the steps of making the MVC Music Store sample (directly interacts w/ EF model from MVC actions as well as other objects) testable: blogs.lessthandot.com/…/continuous-deli

    It uses MS Test and Rhino Mocks, but it could just as easily be done with other frameworks/libraries. The full source and history is available (public hg repository on bitbucket).

  4. Nice write up and a very nice course on Pluralsight.

    Be warned to use the abstracted testable DbContext though. Linq to Entities does not implement everything of IQueryable and/or at elast not everything the same as Linq to Objects. This means that your tests could say everything is fine, while the code will not work as expected when using the real Entity Framework DbContext.

    Just make sure that you back up the Unit Tests with proper Integration Tests that do hit EF with the real database.

  5. Given that Entity Framework lends itself well to testing when an in-memory provider is used, why does the Entity Framework team not develop a supported in-memory provider with complete LINQ support and semantics for use there?

    I’m currently using Effort (effort.codeplex.com) and can put logic in methods that I can use in production code as well as in tests, but that only works as long as Effort tracks EF developments.

  6. Hi guys, Im also using DropCreateDatabaseAlways and my "migrations code" is never called. Even using MigrateDatabaseToLatestVersion its not called.

    I have migrations enabled and one custom index for testing (I have changed the migrations file and manually added the index creation for one table).

    When I use "Update-Database" from package manager console it works allright.

    When I use the DBInitializer it creates the database without the index….

    Any thoughts?

    Thoughts?

    Bruno

  7. @Julie, If unit test shouldn't hit DB, then where should I verify if the relationships are converted in the FKs as I wanted them to be and any other DB design related thing in the code first approach?

  8. @Jignesh (we already chatted on twitter but this is for others). You could write an integration test (like a unit test but has real interaction with EF & the DB) and then just look at the db. That's how I do it. If you want to see how Code First interprets your model, then use the EF Power Tools (from Visual Studio Extensions/Gallery) and view the edmx. Here's a related blog post : thedatafarm.com/…/entity-framewor

Leave a Reply to Lynn Langit Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.