TDD e ADO.NET Entity Framework

"O acoplamento forte da infra-estrutura de persistência para as classes de entidade elimina em grande parte a capacidade de usar eficientemente ciclos de feedback muito apertados na lógica de negócio com testes automatizados. Em seu estado atual, classes de entidade EF não pode ser efetivamente unidade testada de forma independente do banco de dados.

A eficiência de testes de unidade automatizada de objetos de comportamento é em grande parte uma questão de quão fácil a mecânica da configuração de dados de teste são e como rapidamente os testes podem ser executados. Usando o banco de dados real fará a configuração de dados de teste mais trabalhoso, introduzir dados para satisfazer as restrições relacionais que não são pertinentes para o teste, e fazer a execução do teste de uma ordem de magnitude mais lenta.

A capacidade de uma equipe para fazer design evolucionário e entrega incremental é danificado por falta de atenção do Entity Framework para princípios de design de software fundamentais como a separação de interesses ".

Descaradamente roubado aqui: http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/

Se você está procurando especificamente para ferramentas DAL-geração você terá um tempo difícil integrar isso com TDD. A maioria das ferramentas de geração de dal Sei também gerar seus objetos de negócios e fortemente par-los para a tomada de DAL teste difícil.

Você pode olhar para ferramentas ou de mapeamento como nHibernate e talvez LINQ to SQL que permitem "ignorância persistência", você pode definir seu negócio objetos si mesmo e eles não têm ligações à DAL ou qualquer outro código de infra-estrutura. Isso faz com que testar sua lógica de negócio separadamente a partir de seu banco de dados muito mais fácil. Achei também permite outro cenário de como os clientes conectados ocasionalmente muito melhores.

Concordo que a versão 1 do Entity Framework é um crime contra a concepção e definitivamente tem o meu voto de não confiança. Eu credito a equipe de produto EF embora para reconhecer a falha e responder abrindo seu processo de design para a comunidade. O próximo lançamento não vai ser perfeito, ele pode até não estar pronto para uso em um aplicativo de nível de produção, mas eu acho que eles estão finalmente começando a entender o que é importante para aqueles de uso que sabem que mau design é mau negócio. Dito isto ... Eu ainda sou suspeito. Contínuo feedback em tempo de design é novo para esses caras e eu li algumas declarações sobre o blog ADO.NET que levantar brilhantes, bandeiras vermelhas. Vamos ver como ele vai com o lançamento do .NET 4.0.

Eles parecem estar a tentar embora:

Test-Driven Development Passo a passo com o Entity Framework 4.0

Embora, a pergunta original foi respondida, eu sinto que eu poderia acrescentar algo:

Atualmente, estou usando o Entity Framework 4.0 em um site de intranet que estou construindo. Eu sou capaz de testar tudo na minha lógica de negócios e controladores sem uma conexão de banco de dados usando o apoio POCO que tenha sido adicionado.

Embora, do POCO pode ser gerado a partir do novo modelo de t4 incluído no VS 2010, algo que eu não tenho sido capaz de encontrar em VS 2010 é um modelo de t4 para gerar o contexto do objeto (o contexto de objeto funciona basicamente como um construído em unidade de trabalho para EF e é essencial para mapear seus objetos EF para Poços). Felizmente Joachim Lykke Andersen em seu blog Entity Framework 4.0 Beta 1 - POCO, ObjectSet, Repositório e UnitOfWork escreveu um modelo de t4 para gerá-la e tem sido muito útil. Se você procurar uma solução usando o EF4 que é testável sem uma conexão de banco de dados Eu recomendo implementar algo semelhante ao seu solução que inclui um repositório genérico, a unidade de embalagem de trabalho, e uma unidade de fábrica de trabalho. Tem sido muito útil.

Melhor da sorte.

Essa resposta foi alterado para "Sim, você pode".

Você pode gerar POCO e as interfaces usando modelos T4 personalizados tais como https://entityinterfacegenerator.codeplex.com/ , em seguida, criar zombando objetos para testar EF dentro e fora sem bater o banco de dados.