TDD and ADO.NET Entity Framework

问题:

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.

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.

The question is: how do I apply a TDD approach 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?

回答1:

One of the big critiques against the Entity Framework has been that it is inherently hard to test, for example in the ALT.Net Vote of No Confidence that gef quoted.

Here is a blog post discussing how to get around this, and be able to test your code without hitting the database, when using Entity Framework.

If testability is a big concern, you might want to look at another ORM framework, such as NHibernate, at least until Entity Framework 2.0 is released.

回答2:

Although, the original question has been answered, I feel like I might add something:

I am currently using the Entity Framework 4.0 on an intranet site I'm building. I am able to test everything in my business logic and controllers without a database connection using the POCO support that has been added.

Although, the POCO's can be generated from the new t4 template included in VS 2010, something that I haven't been able to find in VS 2010 is a t4 template for generating your object context (the object context basically works as a built in unit of work for EF and is essential for mapping your EF objects to POCOs). Luckily Joachim Lykke Andersen in his blog post Entity Framework 4.0 Beta 1 – POCO, ObjectSet, Repository and UnitOfWork wrote a t4 template for generating it and it has been very helpful. If you pursue a solution using the EF4 that is testable without a database connection I highly recommend implementing something similar to his solution which includes a generic repository, unit of work wrapper, and a unit of work factory. It has been very helpful.

Best of luck.

回答3:

I agree that version 1 of the Entity Framework is a crime against design and it definitely got my vote of no confidence. I credit the EF product team though for acknowledging the failure and responding by opening up their design process to the community. The next release isn't going to be perfect, it might not even be ready for use in a production level application, but I think they're finally starting to understand what's important to those of use who know that bad design is bad business. That being said... I'm still suspicious. Continuous design-time feedback is new to these guys and I've read quite a few statements on the ADO.NET blog that raise bright, red flags. We'll see how it goes with the release of .NET 4.0.

They appear to be trying though:

Test-Driven Development Walkthrough with the Entity Framework 4.0

回答4:

"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/

回答5:

If you're looking specifically at DAL-generation tools you'll have a hard time integrating this with TDD. Most dal generation tools I know also generate your business objects and tightly couple them to the DAL making testing difficult.

You can look at OR-mapping tools like nHibernate and maybe Linq to sql that enable "persistance ignorance", you can define your business objects yourself and they have no links to the DAL or any other infrastructure code. This makes testing your business logic seperately from your database much easier. I found it also enables other scenario's like occasionally connected clients far better.

回答6:

This answer has changed to "Yes, you can".

You can generate POCO and interfaces using customized T4 templates such as https://entityinterfacegenerator.codeplex.com/, then create mocking objects to test EF in and out without hitting the database.