I have a behaviour for which I need to implement real functions and mock versions for testing. Right now I am using three modules to do this: the behaviour, the live and the mock. It makes my file structure and naming kind of a pain.
Is something like this possible?
def MyApp.MyModule do
@behaviour MyApp.MyModule
@callback myfunction(atom, list) :: :ok | :error
def myfunction(arg, opts) do
...
end
end
The Ecto.Repo behaviour has something similar where the default function implementations are in a __using__/1 macro, but I don’t need any code injection.
However you should be able to have a module that both defines and implements a behaviour, I used to do it back in the Erlang days for a few ‘default behaviour’ things.
Better question though, why? There are almost always better ways.
You should never really mock functions, ever, you can mock a process, but if you are mocking functions then something is almost certainly done wrong. What are you trying to actually achieve with a full example we can run ourselves?
I realized that after I submitted the topic late Friday afternoon
The mocks are for an application that talks to a third party API. I’m trying to implement the application in a way that allows for proper testing.
I built an Elixir library for Plaid, the financial data service. I’m using this application as part of an umbrella application that is my larger project. I’ve since refactored the Plaid application to implement the recommended best practice for testing functions that call a third party. Here is a gist that shows the implementation for the Plaid /connect endpoint refactored to use this best practice. A single endpoint contains three files in the following directory structure:
Plaid.Connect.ex is the behaviour and documentation Plaid.Connect.Live.ex is the implementation Plaid.Connect.Mock.ex is the mock
In my dev and test environments I can reference the appropriate module using the config.
This works great, but it seems like it can be refactored to something like I outlined in my first post. I’m so interested in doing this because I’d like to deploy this testing practice in other applications of my umbrella project. All the applications talk to each other, and I need to mock those client API functions in order to write proper unit tests. I’d like to be able to do so in a way that allows me to enforce explicit contracts without creating a complicated directory structure. If I can put the behaviour and implementation in the same module, then I can put all the mocks in another location (like a testing folder) which makes things clearer:
+ lib
+ plaid
- connect.ex
+ test
+ lib
+ support
+ mock
- connect.ex
Plaid.Connect.ex is the behaviour and implementation Plaid.Mock.Connect.ex is the mock
I use behaviours with my modules exactly the same way, and the reason is also testing. I am using mox for testing and I do declare my behaviours and implementations in the same file. In fact, a behaviour is declared next to the function I am about to write.
I just use the behaviour to make sure my mocks follow the same interface as implementations.
You are not restricted to define only a single module in a single file. What name a file has is also not restricted to be the same as the module name.
Of course, it usually is better for readability/understandability of code to not break these two conventions, but there are some common cases in which it makes sense to do so:
Defining implementations for built-in datatypes in the same file as the definition of the protocol.
Defining a module that does not really exist ‘on its own’ inside (or in the same file) as another module. For instance when defining exception structs, ‘nested’ structs, etc. The given example also falls under this, I think
So I could see just having a single file myapp/module.ex file, which contains
defmodule MyApp.Module.Behaviour do
...
end
defmodule MyApp.Module do
...
end
But then again, personally I would like having more, shorter, files over longer, more complicated ones. Also, your testing implementation of the behaviour probably should live in e.g. test/support/*.ex files, such that your testing implementation is only loaded in the test environment.
yeah, two modules would work. Although it could be nice if there was a way to define the behaviour and implement it in the same module (although that might be a bad idea)
Ah no, I don’t think you can do that. I was thinking about the same file but two modules too, precisely what @Qqwy suggests. Probably you can nest the modules too and have like inner module that defines behavior and outer module definig implementation, something like this (untested):
defmodule MyApp.Module do
defmodule Behaviour do
...
end
...
end
Having the same module expose a behaviour and implement it breaks the Single Responsibility Principle, which indeed many software developers see as a Bad Idea™.
I think it has been a conscious choice to not allow this .
