Interfaces for Aggregates?

[@nbarnwell]

I have Application Service classes that are responsible for coordinating behaviour contained in Aggregates. I have nice simple unit tests for the actual behaviour in the aggregates (I'm using an event sourcing approach so I'm comparing events generated by the invoked behaviour against an expected list of events), but I'd like to test the Application Services as well.

Since the aggregates are being tested I want to test the application services in as simple a fashion as possible. I'm considering mocks of aggregates and other services used by the application services so I can assert that they invoke the correct behaviour, but that would require Aggregates to have interfaces (so mocks or fakes can be instantiated).

What are people's thoughts on having interfaces for ARs?

Many thanks in advance.

[opie]

These seem like integration tests you are composing, not specifications. Introducing interfaces in test-after development so you can simplify tests is missing the point of an interface (a contract) IMO. Unfortunately the static typed languages make this kind of stuff a PITA, it might be justified if the cost of interface explosion and maintaining them is worth it. If these are just tests on the command handlers, then personally I don't test them since they are supposed to be dead simple anyways. If there is something more complicated, you might consider doing more of a black-box testing where you test the events being emitted from a higher level.

hth

mike