wfgilman
Can you define a behaviour in the same module that implements it?
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.
If not, why?
Most Liked
wfgilman
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
hubertlepicki
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.
wfgilman
bump ![]()
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








