Если вы пытаетесь выполнить модульное тестирование своих запросов, я настоятельно рекомендую просто настроить тестовую базу данных и протестировать их на реальных данных.Использование IObjectSet<T> для замены коллекции в памяти для ваших модульных тестов - плохая идея.Существуют различия между тем, как запрос linq выполняется под linq-to-objects, и тем, как он анализируется в команде T-SQL, а именно в том, как обрабатываются пустые значения.Например,
db.People.Where(p => p.AccountNum == variable);
Если это использует linq-to-objects (как в некотором наборе объектов памяти, который вы вставили в качестве замены для IObjectSet<T> для ваших модульных тестов), то это будет работать отлично.Однако, если вы выполняете это для базы данных, то, если переменная равна нулю, ваш запрос будет прерван, так как будет сгенерирован запрос
WHERE [peopleTableAlias].[AccountNum] = @param1
, с @ param1 равным нулю, что будет бесполезно,так как вам действительно нужен сгенерированный запрос IS NULL.
Если, однако, вы хотите проверить свою бизнес-логику, которая вызывает ваш EF datacontext, то я бы сказал, чтобы обернуть эти запросы в объекты DataAccess, отметьте вашкак виртуальные методы, внедряйте указанные DAO там, где они необходимы, и в своих модульных тестах заменяйте либо ручные макеты, которые переопределяют эти методы, чтобы вернуть желаемое значение для ваших тестов, либо делайте то же самое с вашей любимой структурой моделирования (например, Rhino).).
РЕДАКТИРОВАТЬ - извините, IObjectSet<T> ограничен EF4, которого у вас, очевидно, нет.Но так как я рекомендовал не делать это для своих модульных тестов, ответ все равно должен применяться.