Are DDD aggregates a good boundary for unit testing?

Question

An aggregate can represent a somewhat stable system boundary.

Does it make sense to write input and output test aggregates to do most testing? In theory we could use an aggregate as a data driven way to do testing. We can create data that is going into our system without a database layer and we get a processed aggregate out. We could potentially specify a lot of cases this way.

The risk here is that we are limiting our ability to modify the aggregates because we may need to rewrite all our test aggregates if an aggregate changes. Although we could migrate them.

Answer 1

Aggregates are definitely good candidates for unit testing because

• They contain part of the domain logic of your application. There's intelligence in them (invariant checking, state transitions, calculations, event firing, etc.) that you want to be correct.

• Aggregates are supposed to be devoid of I/O related stuff. You can compose an Aggregate in memory, call one of its methods to test it and everything will be fast and isolated from the other layers.

Functional changes are IMO not a valid argument against unit testing aggregates - or against any kind of tests for that matter. Tests are executable specification. If the requirements changes, some tests have to change.

Answer 2

When you are going to unit test a class or method which takes an aggregate as input and/or output, think about what the alternative would mean.

You obviously need a way to provide test data to the "subject under test". Either use the existing, public interface, reusing your aggregates for the test data, or you can create an artifical interface just for testing purposes, which duplicates the whole data of your aggregates in a different way. I would not expect this to cause less maintenance effort than the effort you get from an aggregate change.