Я только начинаю с юнит-тестирования и TDD в целом. Раньше я баловался, но теперь я полон решимости добавить его в свой рабочий процесс и написать лучшее программное обеспечение.

Я задал вопрос вчера, что-то вроде этого, но, похоже, это вопрос сам по себе. Я сел приступить к реализации класса обслуживания, который буду использовать для абстрагирования бизнес-логики от контроллеров и сопоставления с конкретными моделями и взаимодействиями данных с помощью EF6.

Проблема в том, что я уже заблокировал себя, потому что я не хотел абстрагировать EF в репозитории (он все еще будет доступен за пределами сервисов для определенных запросов и т. Д.) И хотел бы протестировать мои сервисы (будет использоваться контекст EF) ,

Здесь, наверное, вопрос, есть ли смысл делать это? Если так, то как люди делают это в дикой природе в свете неплотных абстракций, вызванных IQueryable, и многих замечательных постовЛадислав Мрнка на предмет модульного тестирования, который не является простым из-за различий в поставщиках Linq при работе с реализацией в памяти в сравнении с конкретной базой данных.

Код, который я хочу проверить, кажется довольно простым. (это просто фиктивный код, чтобы попытаться понять, что я делаю, я хочу управлять созданием, используя TDD)

контекст

public interface IContext
{
    IDbSet<Product> Products { get; set; }
    IDbSet<Category> Categories { get; set; }
    int SaveChanges();
}

public class DataContext : DbContext, IContext
{
    public IDbSet<Product> Products { get; set; }
    public IDbSet<Category> Categories { get; set; }

    public DataContext(string connectionString)
                : base(connectionString)
    {

    }
}

обслуживание

public class ProductService : IProductService
{
    private IContext _context;

    public ProductService(IContext dbContext)
    {
        _context = dbContext;
    }

    public IEnumerable<Product> GetAll()
    {
        var query = from p in _context.Products
                    select p;

        return query;
    }
}

В настоящее время я собираюсь сделать несколько вещей:

Mocking EF Context с чем-то вроде этого подходаИздевательский EF при модульном тестировании или непосредственно с помощью фальшивой инфраструктуры на интерфейсе, такой как moq, - терпеть боль, которую могут пройти модульные тесты, но не обязательно работать из конца в конец, и подкрепить их интеграционными тестами?Может быть, используя что-то вродеусилие чтобы издеваться над EF - я никогда не использовал его и не уверен, что кто-то еще использует его в дикой природе?Не беспокойтесь о тестировании чего-либо, что просто вызывает EF - так что, по сути, сервисные методы, которые вызывают EF напрямую (getAll и т. Д.), Не тестируются модулем, а просто проверяются на интеграцию?

Кто-нибудь на самом деле делает это без репо и имеет успех?