Some alternatives: - Make it possible to introspect the state and effects of the code on your dependency in the real implementation, and use that instead of a

Some alternatives: - Make it possible to introspect the state and effects of the code on your dependency in the real implementation, and use that instead of a mock. Can then put the assertion into the code (a post-condition, design-by-contracts style) so it always runs, not just for the few explicitly written unit-tests. Those unit tests can be deleted in favor of something that tests something useful, like running the logic on - Return the effect (messages to be sent) instead of doing it internally as a side-effect. Then introspect and verify this data in the test. The dependency on the message queue can now be elimitated, both in test and by the complex piece of logic