0

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?

DmitriBodiu
  • 887
  • 6
  • 19
  • It is really up to you to decide what kinds of design decisions and trade-offs make sense! Do what you think will help you be the most productive! – poundifdef May 30 '18 at 14:36
  • 1
    I understand what you mean, because I thought about it too. You are testing the adapter, so for checking the test of writing I wouldn't use the reading, because it belongs to the adapter too..you should read the database with some other program of the db, or fir example check the writing with a db trigger listening the inserts. – choquero70 Oct 23 '18 at 22:17
  • Gerard Meszaros talks about it too in his book "xUnit test patterns", pages 172-173. He mentions "DBUnit" as a test tool to insert data for testing "read" operations, and to check the content of the database for testing "write" operations. – choquero70 Oct 23 '18 at 22:34

1 Answers1

2

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.)

Markus Pscheidt
  • 5,297
  • 4
  • 44
  • 63
  • No, my question is whether I should reuse persistence library in my integration tests project or create a new one with anemic entities to not have reference to my domain classes... – DmitriBodiu May 24 '18 at 05:50
  • 1
    Writing a separate set of entities sounds counterintuitive, especially for integration tests. So, no, rather not. – Markus Pscheidt May 24 '18 at 07:18
  • What do you mean by entities? Domain models with behaviour? Because my persistence layer has ref to domain models, and this is what makes me unsure... – DmitriBodiu May 24 '18 at 08:21
  • Entities would be domain classes that can be stored and retrieved from the database. Domain classes are at the heart of DDD (and the hexagonal architecture that you added as keyword to your question). So it's hard to write any test without them. There cannot be a definite answer, because you should weigh the pros and cons in your situation. But as a general rule, you could include your domain classes in integration tests. For pure unit tests that focus on a single class you can think of mocking that class' dependencies. – Markus Pscheidt May 24 '18 at 08:30