I like the concept you mentioned earlier, passing module to the function parameter.
But how can I ensure, that user pass the right module as function parameter, that contains the function?
May I solve the problem with protocol?
kostonstyle
0
Korbin73
Generally speaking, this question comes up a lot when people are coming from OO languages. @mkunikow makes a valid point that you don’t need it. The solution is fairly simple especially when it comes to testing. If you take the following steps, you won’t need to mock your functions that are touching the outside world.
-
Keep your impure functions separate from your pure functions. If you have a function that touches a database, calls a webservice, gets the date, etc. Or anything that touches the outside world it should be put in a separate module/function and there should be only one place in your program where it’s called and that data gets passed to your pure functions.
-
Your unit test will only need the stubbed data that would have come from an impure function like the data that would come from a webservice or a database.
The only time mocking is necessary is when you are calling impure functions from pure functions and they are intertwined (this is true even in OO languages). However, if you keep your impure functions separate from your pure functions then there is no need to have DI or a mocking framework when unit testing.
4
JEG2
Author of Designing Elixir Systems with OTP
Korbin73
I know, I was referring to that’s the reason why it’s used in OO languages in the first place 
0
bobbypriambodo
Throwing another article out here: Mocks and explicit contracts.
It presents several ways to “inject” dependencies to your functions, specifically by 1) defining the dependency module on your config, 2) passing the dependency’s handler function as the caller params, or 3) same as 2 but passing the dependency module altogether.
These three approaches allow you to use mock dependencies for your tests.
My initial guess is to use a combination of behaviors and typespecs.
This article echoes José’s Plataformatec article I shared above on dependency injection methods, so I think you can use that as a base. The only thing it left out is for you to validate if a module has adopted a specific behavior. I’m not sure at the specifics on how to do that, though.
1
jwarlander
Mazyod
I’m surprised this topic didn’t spark any discussions around GenStage?
Personally, I’ve been using a pattern similar to Pact, but I have an item in the TODO list to properly learn and understand GenStage to decouple my system. Granted, it won’t solve your synchronous usecases, but I believe it’s worth a mention.
0
mkunikow
svarlet
There is one line in Jose’s blog post that is intriguing:
Finally, you could also make the dependency a data structure and define the contract with a protocol.
Can anyone illustrate this for me?
0
michalmuskala
Just to follow up, I’ll give here the same example for this I gave in Slack.
We can define a protocol for our use case - e.g. a repository of users:
defprotocol UserRepository do
def get(database, id)
end
And then we can define two implementations - one based on a real database and one based on a simple in-memory ETS store:
defmodule Database do
defstruct [:ecto_repo]
def new(repo), do: %__MODULE__{ecto_repo: repo}
end
defmodule EtsDatabse do
defstruct [:table]
def new(), do: %__MODULE__{table: :ets.new(__MODULE__, [:set, :public])}
end
We can then implement the protocol for those data structures
defimpl UserRepository, for: Database do
def get(%{ecto_repo: repo}, id) do
repo.get(User, id)
end
end
defimpl UserRepository, for; EtsDatabase do
def get(%{table: table}, id) do
# assuming {{User, id}, struct} tuples in ets table
:ets.lookup_element(table, {User, id}, 2)
end
end
That’s a simple sketch of a protocol-based dependency injection.
8