-
Notifications
You must be signed in to change notification settings - Fork 113
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cannot wait (with timeout) for expectations #112
Comments
This would be great! I have this problem when testing async work triggered by AMQP messages. My current workaround for this goes like:
In case that helps anyone. EDIT: This technique isn't reliable in all circumstances because the test can still end before the process finishes 😕. Which in my cases leads to a failure as the test is supervising and shuts down the process abnormally. |
I just tripped exactly over the same stuff and was looking through the docs on how to solve this. |
@Odaeus I use the same technique, which is actually accepted in the community, cosidering that it's also suggested in the documentation of the Mox library. In my case I usually do the following:
|
When the external request is not the thing you are testing, you may be interested in using the stub/4 function. It was added specifically for this case. Added here #58
|
This is a nice and clean phoenix integration test. It verifies that, when a GET request hits the
/welcome
route:/an/external/service
routeEverything is good, until we face a different (quite common) async scenario.
Let's imagine that our Phoenix application, when it receives the
/welcome
GET request, it spawns a new process to contact the external service and it response synchronously with the 200 response. Since with ExUnit theverify_expectations
is executed with hooks automatically at the end of the test:Usually popular http mocking frameworks solve this problem adding some waiting capabilities to the expectations (ie. do not fail immediately, do it if expectations are not satisfied in xxxx seconds). We could add some options as keyword list as last optional argument:
What do you think? I would be happy to work on it and I have some ideas:
polling_interval
) if the expectations are satisfiedreceive
with timeout otp functionalitiesBypass.wait_to_receive(bypass_instance, request_count: 3, timeout: 2_000)
)The text was updated successfully, but these errors were encountered: