Comment by Miklos S on "Purify Your Tests"

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?

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

Search Hashnode