3

Background:

My company's current structure is using Plinqo/Linq to Sql to create "data access objects", and then use a custom set of CodeSmith templates to build "business objects". To make a very long story short, these two sets of objects are very tightly coupled and, with Linq to SQL, lead to pretty ugly workarounds.

The Plinqo templates do a direct 1:1 mapping of table to class after generating the dbml. This leads to some comfort in that if the database changes, there is a compile-time error on the business object side (or application side).

I am slowly trying to prove out the benefits of EF 4.1 (Code First) to map to the existing schema, but this "type safety" of code generation has come up as a big issue in a key stakeholder's mind.

Problem:

So in entity framework 4.1, I am using code first to map to the existing database.

  • Poco domain objects
  • EntityTypeConfiguration for each mapping

What would you suggest as a test project for ensuring that the mapping to the schema is sound? Should I just create a unit test project and do retrievals of each object or is there a better way?

Thanks!

junkyspace
  • 365
  • 4
  • 15

1 Answers1

1

I used one base generic integration test performing CRUD operations and derived tests only contained methods for creating entity and validating results of each operation. Each test method run in transaction scope which didn't commit so the test database was still in initial state.

This can be further improved in scenarios where you start to use repositories and instead of working with single entity types you will start to work with aggregate roots. In such case creating correct integration tests manipulating aggregation roots is very handy.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • Thanks. I figured that some form of unit testing would be the best approach. I am responsible for implementation of the "data access" (persistence) side of the equation. I am creating generic repositories (proof of concept) and encouraging the domain object owners toward the aggregate root approach. – junkyspace Jun 24 '11 at 15:17