BitGonzo
Sensible way to abstract away request client library in my application?
I’ve started to test my application and immediately run into the mock debate. Just done reading:
The above suggests using explicit contracts and config variables to manage environment-specific dependencies initially, and then goes on to suggest the simpler method of injecting dependency directly.
However, my current method is a little different. I am using explicit contracts and delegation such as:
config :myapp, request_client: MyApp.Tesla.Request
defmodule MyApp.Request do
@client Application.get_env(:myapp, :request_client)
defdelegate make, to: @client
@callback make(etc) :: etc
end
defmodule MyApp.Tesla.Request do
@behaviour MyApp.Request
use Tesla
plug Tesla.Middleware.Retry, delay: 1000, max_retries:: 3
def make do
# perform request, return response
end
end
This gives me a common interface and call MyApp.Request.make, while also giving me the ability to switch out the client with configuration, which I will use during testing.
Does this look sensible? Is there something inherently wrong with the above approach or, in your opinion, an improvement?
The second question is about testing MyApp.Tesla.Request – perhaps I can switch out the client I use in testing, but surely I still need to test that my Tesla request is configured/running properly.
Most Liked
BitGonzo
Awesome! I’m on Vim. I imagine there is a plugin, or could write a simple one. At the minute I’m just running dialyzer as part of my build process.
NobbZ
So dialyzer is totally right.
Tesla.get/* and Tesla.post/* all are returning Tesla.Env.t according to their @spec. A Tesla.Env.t will never match a {:ok, _} as it is a struct, not a tuple.
If though Tesla.get/* does return a tuple instead, you need to file a bugreport at tesla to fix their specs (or implementation).
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









