Should my integration tests reuse persistence library to have access to db?

Question

I have an implementation of DDD.IdentityAccess.Domain which contains IUserRepository abstraction. There is another dll -> DDD.IdentityAccess.Persistence.Sql which contains implementation of the IUserRepository abstraction. Now, I want to test my IdentityAccess all way down -> Api -> DomainLogic -> Database. Let's take a 'CreateUser' usecase. I call 'CreateUser' through my httpClient, then I want to query db to check if the user is actually added to db. I don't have 'user/id' operation on my rest api, so the only option is to use DDD.IdentityAccess.Persistence.Sql but it will bring dependency to DDD.IdentityAccess.Domain. Should I reuse this dll, or create another DAL, which is not related to Domain?

Answer 1

This is less related to domain driven design than to organizing your test setup.

Integration tests are expensive to write, but can bring enormous value by showing that several components work together as expected. It's a tradeoff.

That said, if I understand you correctly, your question is if you should mock the sql data access object(s) or go down all the way to the database, executing the same sql statements.

There isn't a right or wrong answer here. If the focus is on testing business logic, then concentrate on testing the domain and mock the database access layer.

If the focus is on testing that a simple save operation works from top to bottom, then don't mock. (But use a test database, of course.)