Действительно ли Typemock является единственной платформой, которая может дразнить Linq К классу Таблицы SQL?

В этом случае есть два стандартных подхода к модульному тестированию:

1) Не тестируйте платформу - если зависимость находится от класса фреймворка, вы не пишете тесты, где это взаимодействие проверено. Обычно это означает, что вы заменяете зависимость во время тестирования, но в вашем случае это, вероятно, означает, что вы вставляете саму таблицу.

2) Оберните платформу - если вам нужно протестировать что-то, что взаимодействует с платформой, напишите слой оболочки для соответствующих компонентов

Также следует рассмотреть возможность интеграции и приемочного тестирования. В обоих этих случаях вы обычно просто принимаете зависимость в том виде, в котором она существует в вашем приложении.

Что конкретно вас беспокоит при тестировании, которое вам нужно, чтобы напрямую имитировать / заменить этот класс?

Изменить:

Кажется, как будто ты Мы стремимся избежать переписывания кода, чтобы он был более тестируемым. Именно здесь TypeMock превосходит всех, и именно поэтому некоторые сторонники тестирования считают, что TypeMock может привести к проблемам. Однако это правильный инструмент для работы, если вы категорически отказываетесь реструктурировать свой код для проверки.

Правка №2:

Возможно, я слишком одержим этим, но давайте рассмотрим более проверяемый шаблон:

Organization()
{
    HasUser(name)
}

OrganizationDAL
{
    Organization LoadOrganization(id)
}

OrganizationServiceFacade
{
   IsUserInOrganization(name, orgid)
   {
       return OrgDAL.LoadOrganization(id).HasUser(name)
   }
}

Тест естественного содержания организации для пользователя больше не должен зависеть от платформы, у вас должна быть возможность внедрить источник данных. OrganizationDAL отвечает только за загрузку организаций, а не за возврат информации об организациях (хотя есть способы помещать запросы на этот уровень, если необходимо). OrganizationServiceFacade несет ответственность только за предоставление комплексных услуг, который должен удовлетворять имитацию и избегать необходимости в дополнительных модульных тестах (это интеграция или, возможно, даже цель принятия), поскольку это класс-оболочка. В зависимости от того, как вы строите организации, вы можете вводить данные, не полагаясь на конкретное представление о том, как эти данные работают.

Вы можете рассмотреть возможность использования шаблона репозитория, в основном это предложение Майка «обернуть платформу». С его помощью вы будете издеваться над IRepository, а не над DataContext.

http://blogs.microsoft.co.il/blogs/kim/archive/2008/11/14/testable-data-access-with-the- repository-pattern.aspx