Imo that kind of thinking is a trap. You by definition now have two implementations, not one. It doesn’t matter that only one is used in production.
In the case of the method override one of them is not leaking into production. The changes are contained within the test code.
Which I think is a decent scope for a small-scale need.
That’s fair. But I mentioned you don’t need to go the explicitly passing route. You can just as well start some global process somewhere, which provides the dependency to be used. Call that in your code and you don’t need callers of said code to change. Same with
Application.get_env. That’s also global state you can read without needing callers to be involved.
That’s what I call a lot of ceremony for a small-scale need. The ergonomics feels off.
The big piece here is “global state” no matter the technical implementation. The technical path chosen by Martin Fowler was global state through a static class variable.
Fair point, but not the one I want to debate. In the example I provided there is no global state.
And I’m specifically interested in the compact and ergonomic solutions. Everything we discussed so far default ways in Elixir, they are well-trodden, I wouldn’t come here to ask/hear about a technique I’ve used a hundred times. That’s boring and a waste of time :\
