I think there's an argument to be made that if the desire for testing is a main driver for your architecture then your tests are too granular, and you aren't testing any internal integration points. In my experience that means that your tests are so tied to your current architecture that you can't even refactor without having to rewrite tests.
mocking / interaction / expect breaks encapsulation to perform "testing".
Thus it is often a test of the implementation's assumptions when first written, and even worse, when the code is maintained/edited, the test is merely changed to get it to pass, because unit tests with mocks are usually:
1) fragile to implementation
2) opaque as to intent
Whereas input/output integration points are more reliable, transparent, and less fragile to implementation changes if the interface is maintained.
However, if you must do mock-level interaction testing, Spock has made it almost palatable in Javaland.
This is one area where functional fans get to make the imperative folks eat their lunch.
