Great Series Daniel! In general I think code where order of execution matters should be tested by mocks or via your purified methods. However, often the code interacting with side effects is a use case or a controller. Wouldn't it be better to focus on purism in domain logic and test these plumbing components in a more functional / full blown way? E.g in-process testing by using real dependencies. You can cover a whole business flow in a single test to just see if all components were called or not. Now I know you add more logic to this in the next articles but doing so will make changes less convenient. On another note, with this method of 'leaking' side effecting code's result in the use case I see two problems. is that often we rely on properties of the loaded data/entity to make optional sideeffecting call (e.g isSubscribed -> send Email also). So in your example we could fix that by using some type bounds but it will make the testing part more awkward. We also typically want to return a DTO instead of the actual persisted value(s) in which case it again will be hard to work with this code. What do you think?