This tweet stopped me in my tracks because I couldn’t reply in a tweet:
Stephen Coulson @sdcoulson
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:
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!
And just watch the comments fill up with other suggestions.
Hope this helps, Stephen! :)