Seeing how much pain you are having testing this side-effectful operation, have you considered applying the functional paradigm?
Static methods aren't smells. Quite the opposite infact. Methods with side effects, as indicated by the void
keyword, are what's smelly about that code snippet. Those kinds of methods generally are really hard to test and understand (as you noticed I suppose). When dealing with effects, consider returning meaningful values (like maybe a Try
or a Future
depending on what your method does; have a look at vavr) instead. That is, exchange the side effect with a data structure that deals with it in a functional way (the keyword here is effectful programming in the context of functional programming). And don't mutate state (your Item
) in place. Rather use immutable data structures and return a new instance with updated values (you can use lenses for this).
What you end up with is a bunch of functions for which the values they return depend only on their argument. This feature is called referential transparency: you can replace every call of that function by its value, no matter the computational context. A function exhibiting this feature is called pure. That value you can then easily define assertions against in your unit test without passing any mocks.