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!
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.
you can also use free, open-source ApprovalTests – blog.approvaltests.com/…/whats-new-in-ap
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.
Mehfuz Hossain has written some posts around mocking and Entity Framework using Telerik’s JustMock. Here’s one: msmvps.com/…/mocking-constru
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).
Thanks Lynn, Jim, Henri and El. This post and comments may end up being a useful resource! 🙂
Allen Scott has an old but good article using Moq with EF. Would still work with IQueryable and DbContext today. msdn.microsoft.com/…/ff714955.aspx
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.
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.
Thanks for showing up the options. I am looking for a solution when database first or model first is being used. Please see my question on stackoverflow stackoverflow.com/…/ef-database-mod
Thanks you very much!
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
@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?
@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