0
votes

My Unit Test project (NUnit) is created to test Business Logic only. The vast majority of this logic is in my Business Logic project. I have a separate DLL with all of this. My application is layered and has a project for UI, Service Layer, Business Logic and Data Access layer.

Currently, UI references Service.Service references the BL, BL references DA. All through project references.

I do have a shared project, which all projects references. It holds DTO objects and some shared ENUMS and some bits of code.

In my data accessor, I have a class "Database" (For example). It has loads of data manipulation methods... get Person, update person etc. I also have an interface IDatabase in the same project.

In my Test project, I want to mock out the database calls. But my Constructor in my BL, has a reference to the database, so I can use IoC. In order to be able to mock that from my unit tests - I need to have a project reference to the Database layer. Is this normal? This is because of IoC and the calling method needing to provide the constructor with the concrete class.

1

1 Answers

0
votes

You could solve this by extracting DB-related interfaces from the Database layer into the BL, and inject those in constructors, instead of the actual implementations. This is in fact recommended, for example if you wanted to be able to plug in a different layer instead of DB (other DB, file/external service etc) - this would just require another set of implementations for those interfaces (say IUserQuerier -> DbUserQuerier, FileUserQuerier etc)