Can you define a behaviour in the same module that implements it?

bump

Weekends are slow. ^.^

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:

+ lib
   + plaid
     + connect
       - live.ex
       - mock.ex
     - connect.ex

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

Any thoughts on this?

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.

Can you show an example of a module implementing it’s own behaviour? Do you get a compilation warning from that?

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:

1. Defining implementations for built-in datatypes in the same file as the definition of the protocol.
2. 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.

Here is an example of how to tell Mix to add extra files in the test environment, and here you can see that the folder in that particular library contains an Ecto.Repo and some schemas to be used in the testing.

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

I suspect this may work.

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 .