O teste de unidade com o Entity Framework

Aparentemente, é muito difícil. Eloquentemente por Erik aqui - TDD e ADO.NET Entity Framework

Que tal usar um quadro de zombaria? Parece-me que uma plataforma de simulacros pode ajudá-lo isolaye sua lógica de negócios do banco de dados.

Concordo, um quadro de zombaria é o que você está depois. Você cria "ridicularizado" objetos que não são recuperadas a partir de sua fonte de dados, e você testar os dados desse objeto. Eu pessoalmente tenho trabalhado com Moq, e eu gosto disso - há também RhinoMocks, além de outros.

Você vai querer usar um quadro zombando para recuperar valores simulados em vez de bater os dados reais. Aqui está uma lista de algumas estruturas de zombaria e links para alguns screencasts para ajudá-lo a começar:

• Rhino Mocks

• Moq

Aqui estão alguns screencasts sobre como começar:

• Introdução ao Mocking com Moq
• Rhino Mocks vídeos

Embora os exemplos pode ser muito simplista tentei discutir uma possível solução para esta questão. Trata-se de separação de interesses e nosso querido amigo Dependency Injection.

http://devblog.petrellyn.com/

Contacte-me se você quiser mais detalhes.

Eu gostaria de compartilhar uma outra entrada para esta. Eu era capaz de testar Entity Framework componentes baseados e aplicação usando TypeMock Isolador também. No entanto, é comercial.

Ter um olhar para este post: Apresentando Entity Framework Testes Unitários com TypeMock Isolador

Devido ao fato de que a versão 1 do Entity Framework quebra de alguns grandes princípios de design de software, não há realmente nenhuma maneira de aplicar TDD quando usá-lo em sua aplicação. Meus pesquisa aponta para NHibernate se você está procurando uma solução imediata. Ele foi projetado com o teste de unidade em mente.

No entanto, se você puder esperar, parece haver esperança para a próxima versão do Entity Framework: Test-Driven Development Passo a passo com o Entity Framework 4.0

O BookLibrary aplicação de exemplo do WPF Application Framework (WAF) projecto mostra como uma aplicação baseada estrutura de entidades pode ser unidade testada.

Uma abordagem barata é a criação de um arquivo de banco de dados com a mesma estrutura que seu banco de dados real e definir a cadeia de ligação na sua configuração de teste de unidade para apontar para isso. O banco de dados não precisa ter todas as tabelas que o real tem; apenas os que as necessidades de teste de unidade.

A desvantagem é que você precisa para gerenciar o estado do banco de dados para que os testes de unidade não afetam uns aos outros ou a si próprios durante e entre as execuções.

Eu sei que esta abordagem funciona quando tanto o real e unidade de teste DBs uso SQL Express, mas eu não sei sobre arrancando em um sqlexpress DB para um DB SQL completo.

Sei que isso é tecnicamente testes de integração, mas poderia ser mais barato do que refatorar seu código ou a aprendizagem de uma plataforma de simulacros.

Exemplo seqüência de conexão real:

<add name="DrinksEntities" 
     connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provider=System.Data.SqlClient
     ;provider connection string=&quot;Data Source=localhost\sqlexpress;Initial Catalog=Drinks2;Integrated Security=True;MultipleActiveResultSets=True;Application Name=EntityFramework&quot;" 
     providerName="System.Data.EntityClient" />

Exemplo cadeia de ligação de teste de unidade:

<add name="DrinksEntities" 
     connectionString="metadata=res://*/Model.csdl|res://*/Model.ssdl|res://*/Model.msl;provider=System.Data.SqlClient
     ;provider connection string=&quot;Data Source=.\SQLEXPRESS;attachdbfilename=|DataDirectory|\Inventory.mdf;Integrated Security=True;user instance=True;MultipleActiveResultSets=True;Application Name=EntityFramework&quot;" 
     providerName="System.Data.EntityClient" />

Aqui está uma agregação da unidade de padrão de trabalho + in-memory banco de dados + geração de código T4 para gerar automaticamente uma farsa EF DbContext.

http://mockingcompetence.wordpress.com/2013/05/20/fakingefdatacontext/

há algumas questões (LINQ inválido para consultas EF e nenhuma aplicação FK) com replicar exatamente uma conexão db verdadeira EF neste momento.

No entanto, ter um contexto em memória para executar rapidamente testes de unidade é quase essencial para ser capaz de fazer TDD ou qualquer outro tipo de unidade testar abordagem centrada.

Eu estarei postando atualizações no link acima que eu descobrir mais das questões.

Depois de muita frustração com este eu finalmente ter uma solução que eu estou feliz com, pelo menos, parte do problema.

Primeiro use uma interface algo repositório como:

public interface IRepository
{
    IQueryable<T> GetObjectSet<T>();
}

que podemos utilizar para retornar tanto uma coleção na memória ou uma verdadeira coleção apoiado DB. Próxima encapsular suas consultas em um objeto de consulta com uma interface que algo parecido com isto.

public interface IQuery<T>
{
    IQueryable<T> DoQuery(IQueryable<T> collection);
}

Agora dividir os testes de unidade em 2 grupos. O primeiro grupo vai testar se as suas dúvidas são válidos. fazer isso assim:

[TestMethod]
public void TestQueryFoo()
{
     using(var repo = new SqlRepository("bogus connection string"))
     {
         var query = new FooQuery(); // implements IQuery<Foo>
         var result = query.DoQuery(repo.GetObjectSet<Foo>());  // as long as we don't enumerate the IQueryable EF won't notice that the connection string is bogus
         var sqlString = ((System.Data.Objects.ObjectQuery)query).ToTraceString(); // This will throw if the query can't be compiled to SQL
     }
}

O segundo conjunto de testes de unidade pode então testar livremente sua lógica de negócios sem se preocupar com a etapa SQL compilação que é, de longe, onde nos deparamos com a maioria dos problemas.

A sua não é perfeito por qualquer trecho da imaginação, disparadores, obviamente, não vai ser executado, DB implementado restrições podem ser violados, e alguns problemas com o contexto ea base de dados ficar fora de sincronia podem surgir. Assim, enquanto uma extremidade à outra testes de integração ainda são necessários, é possível pegar o que é IMO a questão mais comum a surgir em tempo de execução em testes de unidade simples.

Você poderia usar na memória base de dados para testar seu modelo Entity Framework. Olhe aqui para mais detalhes