Создать System.Data.Linq.Table в коде для тестирования

Question

У меня есть класс адаптера для Linq-to-Sql:

public interface IAdapter : IDisposable
{
    Table<Data.User> Activities { get; }
}

Data.User - это объект, определенный Linq-to-Sql, указывающий на таблицу User в постоянстве.

Реализация этого выглядит следующим образом:

public class Adapter : IAdapter
{
    private readonly SecretDataContext _context = new SecretDataContext();

    public void Dispose()
    {
        _context.Dispose();
    }

    public Table<Data.User> Users
    {
        get { return _context.Users; }
    }
}

Это упрощает проверку уровня персистентности в модульном тестировании, поскольку я могу просто вернуть любую коллекцию данных, которую я хочу для пользователей (Rhino.Mocks):

Expect.Call(_adapter.Users).Return(users);

Проблема в том, что я не могу создать объект 'users', так как конструкторы недоступны, а класс Table запечатан. Один из вариантов, который я попробовал, - просто заставить IAdapter возвращать IEnumerable или IQueryable, но проблема в том, что у меня нет доступа к методам, которые предоставляет ITable (например, InsertOnSubmit ()). Есть ли способ создать ложную таблицу в сценарии модульного тестирования, чтобы я мог стать счастливым разработчиком TDD?

Answer 1

Я успешно использовал Уровень доступа к данным для создания коллекций объектов домена, а затем использовал linq для объектов. В этом случае тестируемый объект относится только к списку List, который довольно прост для модульного тестирования.

Мне не нравится, когда логические объекты должны иметь зависимости уровня доступа к данным. Они должны остановиться на уровне обслуживания, если даже там. Я обычно использую модель, в которой сервисный уровень вызывает объект доступа к данным для получения списка, передает этот список в любой логический объект, который ему нужен (при необходимости использует linq-to-objects для фильтрации соответствующих данных и вводит их в eiter плоский список, словарь или объектная модель).

Бизнес-объекты становятся очень тестируемыми, хотя они не извлекают выгоду из богатства выведенной модели данных.

Answer 2

Мое текущее решение состоит в том, чтобы обернуть нужные мне функции из Table в класс TableWrapper:

public interface ITableWrapper<TEntity> 
    where TEntity : class
{
    IEnumerable<TEntity> Collection { get; }
    void InsertOnSubmit(TEntity entity);
}

А вот и реализация:

public class TableWrapper<TEntity> : ITableWrapper<TEntity> 
    where TEntity : class
{
    private readonly Table<TEntity> _table;

    public TableWrapper(Table<TEntity> table)
    {
        _table = table;
    }

    public IEnumerable<TEntity> Collection
    {
        get { return _table; }
    }

    public void InsertOnSubmit(TEntity entity)
    {
        _table.InsertOnSubmit(entity);
    }
}

Так что теперь я могу легко высмеивать данные из Collection, а также сохранять функциональность InsertOnSubmit (любые другие функции, которые мне понадобятся в будущем, могут быть добавлены позже).