Una vez que la unidad ha probado que la lógica funciona con IQueryable proporcionada por EF, simplemente no puede probarla con pruebas unitarias burlando EF. Eso siempre llevará a cambiar de linq a entidades a linq-to-objects. En el caso de algo simplificado, la forma correcta de manejar esto en la prueba unitaria es escribir un falso en lugar de simulacro. Fake simularía el comportamiento de la dependencia. En este caso, escribir un falso significa escribir al proveedor de EF trabajando en la recolección en memoria exactamente de la misma manera que el proveedor real trabaja con la base de datos. Escribir tal proveedor probablemente sea un proyecto en sí mismo.
Debido a que una vez que su lógica contiene consultas linq-a-entidades siempre debe probar con pruebas de integración o refactorizar el código para que la consulta en sí sea en método separado (probado por pruebas de integración) y la lógica anterior ahora dependa la clase que contiene el método en vez de EF misma - esto lleva al patrón de repositorio donde IQueryalbe no está expuesto pero el repositorio expone el método para cada consulta necesaria que opera en alguna entidad. Personalmente no me gustan este tipo de repositorios. Here is recent discussion sobre diferentes implementaciones de repositorio.
Si decide utilizar pruebas de integración para cambiar la base de datos a en memoria, con EFv4.1 y el código primero es posible cambiar simplemente la cadena de conexión a SQL Compact 4 y funcionará (a menos que esté usando Llamadas SQL o demandando algunos tipos especiales de SQL en el mapeo). En el caso de EF con el archivo EDMX, no funcionará, porque el archivo EDMX está estrechamente relacionado con la versión exacta de la base de datos. Tener EDMX especial solo para pruebas unitarias no es una opción porque volvería a probar un código diferente.
Here is set of related questions discutiendo los desafíos con la unidad de prueba de código EF y repositorios.