Unit testing the Data Access Layer in a 3-layer architecture

Question

In a typical 3-layer architecture application, there are:

• Business Logic Layer
• Data Access Layer
• Data Storage Layer

I am thinking of test the DAL (especially the one with Entity Framework) without using the real DB. But it's kind of difficult to simulate the complex foreign key constraints in DB. And also a lot of other things.

I am now thinking if this is the right way to Unit Test the DAL? Or which layer is most subject to Unit Testing?

I see some articles trying to mock the DbContext in the Entity Framework. It seems difficult to simulate the foreign key relations with this approach. I am wondering if it is the right location for the seam. Can we mock at somewhere else? Such as mocking around the ADO.NET layer? i.e. An in-memory mock DB for ADO.NET to consume.

Answer 1

Mocking database stuff is notoriously hard, time-consuming and cumbersome. Therefore, a more practical approach would be to setup a test database, let your test run against it, and test the entire persistence thing in combination - this is not exactly unit testing, but far more practical...

Btw.: The typical 3-layer architecture is:

1. Presentation layer
2. Business Logic layer
3. Persistence layer (part of which is the data storage system - mostly a database)

Answer 2

Thomas's answer provides a good way to test your Data Access layer. But it doesn't provide a way to replace it.

A more sound approach to 3-layer architecture is to prevent the Business Logic layer from talking directly to classes in the Data Access layer. That cross-layer communication should be done through an interface you define. The Data Access layer can know about the Business Logic layer, but the Business Logic layer should only know about the Data Access interface, and not care how that interface is implemented.

Then you can replace real data access with fake data access. See Uncle Bob's talk Architecture: The Lost Years.