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.

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