That’s interesting - so in other words do u think I should abstract away e.g. GenServer? 
e.g.
# moduleA
def foo_a(...) do
ModuleB.fun_b(...)
|> actiona
|> actionb
|> ...
end
#moduleb
use GenServer
def fun_b(....) do
GenServer.call(...)
end
def init(..) ...
In the example above I usually stub return data from moduleB.fun_b to write unit tests fro moduleA
Mimic allows me to do it without configuration burden, but I see that using mock implementation for GenServer while testing may work too - GenServer has already behavior - it is enough to mock it’s functions.
The only problem I see it to not easy distinguish of GenServer calls - as we would have to differ them based on pattern matching args which might be not very readable
I mean instead
stub(ModuleB, foo, fn -> returnA end)
stub(ModuleC, foo, fn -> return end)
we would need
stub(GenServer, call, fn _,
{:update, "id"} -> returnA # moduleB call
{:update, "item"} -> returnB # moduleC call
end)
another problem is deep call sequence - we would have to stub all GenServer call/cast down in call stack - where with Mimic we can isolate it right away in the testing module without worring about dependencies very deep down in the code
please correct me if I missed sth 
Please do consider to update Elixir doc then 
Protocols are a mechanism to achieve polymorphism in Elixir where you want the behavior to vary depending on the data type.
ok, so do u suggest to pass env as a first arg to protocol to get different behavior, am I right?
Why not use behaviors instead?
Please do! I would love to read it
The question was - why I should use protocol and passing envs to it - instead of behavior and use Mox?