At least the dummy names would no longer need to be coupled to a certain behaviour, but are just “dummy names”. The behaviour would be defined in each test. But as always it comes with the tradeoffs of mox in terms of async tests.
LostKobrakai
Ninigi
It was late in the day for me, and I honestly didn’t want to spend any time on thinking about your problem in depth, so I just threw in what I thought at that moment in the form of a question. I didn’t even think about defining the modules in your tests - should have been obvious 
- but what jumped out to me was the fact that you did not really care about where the logic for the return value you needed was defined, as long as the return values satisfies your test case. That looked like the perfect example for a mock to me, and you already defined the behaviour, so why not go for Mox.
The way I thought you might want to use it is define one or two mock modules in your test helper, and call the same module(s) multiple times with different return values. That way, the return value would be obvious from the tests and you wouldn’t have to define the modules over and over again.
However, my experience with Mox is limited to communication layers of an app - mainly in the actual implementation of the communication, think HTTP connectors that implement get, post, put, patch and delete - so my suggestion might not be suitable for you at all.
1