We develop some features by creating a rich domain model or Aggregate. This is a graph of entities, with a root, properties with private setters and public methods for operations on it.
This aggregate encapsulates the business logic that allows to change its state. Also, these aggregates can raise events, which basically mean they are placed in a collection for later dispatch from the unit of work (@jbogard I believe I took this from one of your blog posts).
This setup allows us to unit test this logic quite nicely.
With all the logic encapsulated in the aggregates, the handlers mostly take the form of:
- load aggregate from DB (using a unit of work)
- call a method on the aggregate
- store to DB (unitOfWork.Commit)
some times with some extra logic that cannot be embedded in the aggregate for different reasons.
The problem appears when we want to unit test the handlers.
It is very easy to mock the unit of work, to return a specific instance of an aggregate and to assert that the Commit method is called.
The problem is that it’s not straight forward to assert if or which aggregate method was called. The only way we have right now is to assert that the state of the aggregate has changed as expected (looking at some properties). The problem with this approach though is that it leaks information from the aggregate unit tests into handlers unit tests, therefore if we ever change the aggregate we also break a lot of handler unit tests.
The only solution I’ve come up with, that doesn’t imply a big pattern change is to create an interface for each aggregate with the public methods. This would allow to test the handlers with a mock of the aggregate instead of the real implementation (or a proxy of the real implementation). But it feels a bit like forcing something into the domain model just for testing purposes.
What are your thoughts?