[erlang-questions] Mocks and explicit contracts

[José Valim]

>
> First of all, José's approach also mocks globally in the Erlang context.
> It might be different using local modules, but if you enter Erlang, then
> it's automatically global.
>

The article uses a specific definition of the word "mock". So I agree with
you that it is still a global mock but we are not mocking the system per
the post definition (i.e. changing the implementation during tests). It is
a nitpick, sorry, I just wanted to be precise.


> Would you consider, for that case, using instead:
>
>    -ifndef(twitter_api).
>    -define(twitter_api, default_twitter_api).
>    -endif.
>
>    show(Username) ->
>        ?twitter_api:get_username(Username).
>
> Through build tools, you could define (here I'm using rebar3):
>
>    {profiles, [
>        [{test, [{erl_opts, [{d, twitter_api, test_twitter_api}]}]}]
>    ]}.
>

This is a great solution. I will change the article to use a compile time
version of the Elixir implementation as well. Although I would personally
not worry about the cost behind accessing an ETS table, specially for this
example where we are doing an HTTP request and parsing JSON response for
every call, using something akin to a macro is just a better "default".

> Q1: Am I going to need multiple modules there because it's a value I want
to be configurable by users of a library at runtime?

The article was only about handling such cases in your application (no
sharing). The thing is, if you want it to be configurable by users, then as
you said the application environment is not enough. The good news is that
once you provide your configuration mechanism, you have solved the testing
problem as well.

> Q2: Am I needing multiple modules to test alternating configurations?

Yup, I have replied that in another e-mail. It works to some extent as you
can give different responses based on the argument. It depends on the
system. There are simpler (like passing a closure or an argument) and more
complex solutions as well, YMMV.

> I personally prefer to pay the cost of slightly longer test runs
personally, than having my users pay the cost themselves at run time.

That's the only bit I actually disagree. It is not about the performance
cost of the test but it is the conceptual cost of mocks. Specially in
complex codebases where mocking often hides the fact the developers simply
did not define a good contract between their dependencies. That was the
main point of the article, anyway.  :)

Thanks Fred!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20151120/89c1a7d7/attachment.htm>