axelson
Scenic Core Team
I have a question for people who have been using bypass for testing web requests. How do you handle asynchronous tests where the code making the request is pretty far into your Phoenix context?
If I’m testing the module that makes the request directly then as an optional argument I can pass the url with the bypass port, but if the request is happening further down the call stack then I don’t want to be passing that url all the way through the application.
Do people just use mox/meck for this instead?
Trending in Questions
Hey guys,
I’ve got a huge CSV ( around 10 GB ) that needs to be processed hourly
Do you guys have any suggestions what is the best prac...
New
Hello!
Could someone please give me a help/sample code, how to delete a file from s3 using waffle/waffle_ecto from Phoenix app.
I creat...
New
I have what I’ve heard referred to as a “lookup table” in my database. This is a way of assigning codes to common values. One common lo...
New
What approach to take when sending live updates to “random” users Hi! I have a question, I have a little chat app, and when I create a DM...
New
I’m seeing that a list inside a Kino.DataTable will be interpreted as a charlist, even if the Kino.configure() is set to charlists: :as_l...
New
Anyone here using Honeybadger?
My Honeybadger account is being overwhelmed with noise from some bots. Seeing a lot of
Bandit.HTTPError...
New
Hi, I’ve just set up an application with ash_authentication. There is only magic link strategy for now, so there is no confirmation add o...
New
Other Trending Topics
I am happy to introduce the very α version of the new programming language compiled to BEAM.
Welcome Cure.
It has literally three kille...
New
Hobbes is a low-level distributed database for the Elixir programming language.
Hobbes provides a simple, safe, and scalable storage lay...
New
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge & Solve.
They are GUI (Emerge) and State management (S...
New
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
There are three potential reasons for members of this forum to have a look at https://vutuv.de
You are tired or annoyed of LinkedIn.
Yo...
New
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
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixir-ls
- #ai
- #elixirconf-us
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming











Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
trisolaran
whenever I’m in a situation similar to the one you’re describing, I typically make the module that calls the external service configurable so that the external service’s url can be passed as a config parameter. Then, in the config for the test environment (
test.exs), I set the url to be thebypassurl.axelson
Yes, I’ve done that too, but the problem then is because we’re setting the application env to a test-specific value, we can no longer use
async: truebecause the application environment is global configuration.trisolaran
Not sure I understand.
async: trueaffects concurrency of test cases right? How does it affect configuration?stefanchrobot
Sorry if this is unhelpful, but the challenges you’re facing is the reason I’m using Mox which you can use in async tests. I think to make this work with bypass you’ll end up with pretty much similar mechanism that you’d use for Mox.
trisolaran
@stefanchrobot can you explain to me what the challenge is? I’m curious
Why can’t you use
bypassin async tests? Is it because each test will spawn its own bypass process and there will be a conflict if they are all trying to bind to the same TCP port?stefanchrobot
If I’m not mistaken, you can’t do
Application.put_env(and revert it at the end) in async tests because the tests will override the values. As you mentioned, you can do it globally inconfig/test.exs, but the way I understood it is that @axelson doesn’t want a global config.So it seems the options are:
async: falsewithApplication.put_env,async: truewith global config,async: truewith Mox (it uses a global config to replace the real module with the mock).trisolaran
Oh I see now. Thanks! Yes that sounds right. The question of course is “do you really need to set up your test using
Application.put_env”? Personally, it’s something that I try to avoid like the plaguejosevalim
You can look at how we tackled this in Bytepack: bytepack_archive/apps/bytepack/test/support/stripe_helpers.ex at main · dashbitco/bytepack_archive · GitHub
We defined a behaviour for the host (in this case Stripe) and then used Mox to set the Bypass URL as the host.
ananthakumaran
The way we handle this is by having our own config module which is just a wrapper around Application.get_env. If the env is not test, it will just call Application.get_env. If test, it will first check if there are any overrides for the given key and current process. It will also take $callers and $ancestors into account while doing the lookup. We do use Mox in many other cases, but for http api we mostly depend on bypass with the config override
axelson
Thanks! I’ll study that in more detail tomorrow.