Как только логика, протестированная вашим модулем, работает с IQueryable, предоставленным EF, вы просто не можете проверить его с помощью модульных тестов, имитируя EF. Это всегда приведет к переключению с linq-to-objects на linq-to-objects. В случае чего-то упрощенного, правильным способом справиться с этим в модульном тесте является написание фейка вместо макета. Подделка будет имитировать поведение зависимости. В этом случае подделка означает написание EF-провайдера, работающего над сбором в памяти, точно так же, как реальный провайдер работает с базой данных. Написание такого провайдера, наверное, сам проект.
Из-за этого, как только ваша логика содержит запросы linq-to-entity, вы всегда должны тестировать ее с помощью интеграционных тестов или рефакторинга кода, чтобы сам запрос выполнялся отдельным методом (тестируется интеграционными тестами), а прежняя логика теперь зависела от класс, содержащий метод вместо этого в самом EF - это приводит к шаблону репозитория, где IQueryalbe не предоставляется, но репозиторий предоставляет метод для каждого необходимого запроса, работающего на некотором объекте. Мне лично не нравятся такие репозитории. Вот недавнее обсуждение о различных реализациях репозитория.
Если вы решите использовать интеграционные тесты, меняющие базу данных в оперативную память, то это возможно с помощью EFv4.1 и кода вначале, когда вы просто меняете строку подключения на SQL Compact 4, и она будет работать (если вы не используете какой-то специальный прямой SQL вызывает или требует некоторых специальных типов SQL в отображении). В случае EF с файлом EDMX это не будет работать, поскольку файл EDMX тесно связан с точной версией базы данных. Использование специального EDMX только для модульного тестирования не вариант, потому что вы снова протестируете другой код.
Вот набор связанных вопросов обсуждение проблем с модульным тестированием кода EF и репозиториев.