<p>I've been playing with ADO.NET Entity Framework lately, and I find that it suits my needs for a project I'm developing. I also find cool its non-invasive nature.</p>

<p>After generating a data model from an existing database you are faced with the task of integrating the generated model and your business logic. More specifically, I'm used to integration-test my classes that interact with the data store via mocks/stubs of the DAL interfaces. The problem is that you cannot do this using the ADO.NET Entity Framework because the entities it generates are simple classes with no interface.</p>

<p>The question is: how do I apply a <strong>TDD approach</strong> to the development of an application that uses ADO.NET Entity Framework? Is this even possible or should I migrate to another DAL-generation toolset?</p>

"The tight coupling of the persistence
  infrastructure to the entity classes
  largely eliminates the ability to
  efficiently use very tight feedback
  cycles on the business logic with
  automated testing. In its current
  state, EF entity classes cannot be
  effectively unit tested independently
  of the database.
The efficiency of automated unit
  testing of behavioral objects is
  largely a matter of how easy the
  mechanics of test data setup are and
  how quickly the tests can be executed.
  Using the actual database will make
  test data setup more laborious,
  introduce data to satisfy relational
  constraints that are not germane to
  the test, and make test execution an
  order of magnitude slower.
A team’s ability to do evolutionary
  design and incremental delivery is
  damaged by the Entity Framework’s
  inattention to fundamental software
  design principles like Separation of
  Concerns."
Blatantly stolen from here:
http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/