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

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.

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?

Any thoughts on this?