Como você está testando a unidade de pessoas com o Entity Framework 6, deve se preocupar?

Estou apenas começando com testes de unidade e TDD em geral. Eu já brinquei antes, mas agora estou determinado a adicioná-lo ao meu fluxo de trabalho e escrever um software melhor.

Ontem fiz uma pergunta que incluía isso, mas parece ser uma pergunta por si só. Sentei-me para começar a implementar uma classe de serviço que utilizarei para abstrair a lógica de negócios dos controladores e mapear modelos específicos e interações de dados usando o EF6.

O problema é que eu já me bloqueei porque não queria abstrair a EF em um repositório (ele ainda estará disponível fora dos serviços para consultas específicas etc.) e gostaria de testar meus serviços (o Contexto da EF será usado) .

Aqui eu acho que é a pergunta, há um ponto para fazer isso? Em caso afirmativo, como as pessoas estão fazendo isso de maneira natural à luz das abstrações vazadas causadas pelo IQueryable e das muitas ótimas postagens deLadislav Mrnka sobre o assunto de o teste de unidade não ser direto por causa das diferenças nos provedores Linq ao trabalhar com uma implementação de memória, ao contrário de um banco de dados específico.

O código que quero testar parece bastante simples. (este é apenas um código fictício para tentar entender o que estou fazendo, quero conduzir a criação usando TDD)

Contexto

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)
    {

    }
}

Serviço

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;
    }
}

Atualmente, estou pensando em fazer algumas coisas:

Zombando do contexto da EF com algo como essa abordagemZombando da EF ao testar a unidade ou usando diretamente uma estrutura de zombaria na interface, como moq - tendo o cuidado de que os testes de unidade possam passar, mas não necessariamente funcionem de ponta a ponta e apoiando-os nos testes de integração?Talvez usando algo comoEsforço zombar da EF - nunca a usei e não tenho certeza se alguém a está usando na natureza?Não se preocupe em testar qualquer coisa que simplesmente chame de volta à EF - portanto, os métodos de serviço que chamam a EF diretamente (getAll etc.) não são testados em unidade, mas apenas testados em integração?

Alguém lá fora, realmente fazendo isso lá fora, sem um Repo e ter sucesso?

questionAnswers(10)

yourAnswerToTheQuestion