Could you split the split the statemachine behind this out? Make this more of a state + event → next_state type of deal, where you test the steps it takes individually and therefore with only the mocks needed for a certain step?
Plus maybe a single test to make sure the pieces are then wired together well and if you want to be triple secure you can add some (stateful) property tests to make sure you didn’t overlook a permutation of possible events in sequence.
Damn, this sounds amazing 
, do you have an example of how something like this would look like? I have used gen_statem before, I think it can be used for this?
This is exactly the topology I am looking for tests, no repeating tests and making sure the subsequent functionality is called.
I’ve also used a pattern in which I separate the complex conditional logic (not technically a state machine in my case) that decides what resulting action to take from the code that performs that side-effect action. I can unit test the core logic without performing any action. Something like:
def high_level_feature(inputs) do
{function, params} = core_complex_logic(inputs)
apply(__MODULE__, function, params)
end
def core_complex_logic(inputs) do
...
{:action_function, [param1, param2]}
end
Tests can focus on core_complex_logic and cover all sorts of corner cases, etc. and validate that the expected two-tuple is returned. It’s fast, and has no mocks. Sure, technically that apply call is not being covered in these tests, however, there’s going to be one or two higher-level smoke tests that would execute high_level_feature.
This looks like a very basic interpreter pattern. I like it and might employ it in my own code.
Not at hand. But as @gregvaughn suggested I’d start with a module and functions on it and see how far you can get without a process involved – leaving the process to few smoke test/integration tests to make sure the plain logic was wired together with the process callbacks correctly.
This is a pretty interesting approach, the only thing I hate about it is that navigating around such code is very hard, as the LSP will not work.
I guess, as long as you limit all of this to a single module, it should be readable enough.
You don’t need to use apply with this approach. You can do:
def high_level_feature(inputs) do
{action, params} = core_complex_logic(inputs)
case action do
:specific_action -> specific_action(params)
# ...
end
end
def core_complex_logic(inputs) do
# ...
{:specific_action, [param1, param2]}
end
Then the LS should work just fine. This might even be preferable since you can introduce some exhaustiveness checking.
It’d be more verbose of course, but that might be worth the tradeoff. I often like paying the verboseness tax if I’m reimbursed with obvious correctness.
Ha for sure 
But also, the freedom to have specific_action/1 accept whatever the heck params happens to be is nice. That I could switch from
defp specific_action(param1, param2) do
to
defp specific_action([param1, param2]) do
without batting an eye is cool. The latter is even compatible with guards! Sure the @spec would be less helpful (if I were to bother), but I’m already in defp land so I (personally) don’t care so much.
Haha. It’s funny you mention that. While that outline I started with is very simplified, I first learned this technique from a tutorial about the IO monad in Haskell (
yes, I used the “m” word). My core takeaway was to separate the pure logic that can be easily tested from the side-effects that had to be wrapped in a monad. It’s about separation of deciding what to do from actually doing it. I’ve found it a useful distinction.
Fascinating. I find LSP a “nice to have” and have never let it affect how I design my code. Perhaps that reveals too much about me though Still, it is important to recognize it has tradeoffs, like all design decisions do. The case expression is a nice mitigation of your concern.
The part about core_complex_logic that bugs me most is that I’m making a function public that could be private purely for testing purposes. Sometimes I live with that tradeoff, but if it became a concern I could move the core decision logic into a new module with @moduledoc false (which isn’t perfect either).
This could be taken even further. Rather than returning a two-tuple, return some sort of a “command” struct inspired by examples such as Ecto.Changeset or Req.Request plus a module that knows how to “execute” the “command”.