Thanks for the positive feedback! Something else that can help mitigate such issues that I didn't mention in the post is to you can use DTO classes with Option fields and then convert those to better typed internal classes. But that comes with lots of new boilerplate... (Though maybe something like the Chimney library can help.)

Thanks for the positive feedback! Whether you want to write unit tests or full blown functional tests for a component is really a matter of choosing the right tradeoff for your use-case. I find that the maintenance burden of more "realistic" tests tends to be higher, so I have a limited (but non-zero) budget for them. Unit tests (especially purified ones) seem to have a lower maintenance cost, and are relatively easy to write and modify. Purification also helps to make them more resilient to change as it helps narrow down the scope of the test to the exact bits the flow is responsible for. Although in general the tradeoff is really context dependent, in this example where I only test the functionality of a single service (as opposed to the interaction of multiple services), I would gravitate more towards the unit approach. I also find that writing tests like this, or at least thinking in terms of "purified" code helps me crystalize the purpose of the component. You're right in calling this code "leaking", it indeed exposes some internal details of the process that you might want to keep hidden. In the second part of the series I modify the code to "leak" less. I might actually add another (small) article about how to hide some of the type parameters. For question 1, there's no issue with conditional logic here, as you can choose the type parameter to be distinct things in the production flow vs. the test. For example, Bookkept can be Unit in production and Option[String] in the test. Where None will signify that the service decided not to do the bookkeeping flow. For question 2, it depends on how tightly coupled your code is with the DTO. From my point of view, orchestrator code like UberService shouldn't really "care" too much about the specific data types flowing through it. In part 3 I take advantage of that and use even more type parameters to remove any coupling between UberService and the data flowing through it. If you read part 3, let me know if that solves the issue you're concerned with. But basically, for every DTO flowing through the code, I might introduce a type parameter to stand for it, and then mock it out in the test with some simple thing like String . Thanks for the interesting comments

You're right. Shame on me for not running (all of) my code snippets. Will fix. Thanks